| | <<<Back 1 day (to 2012/03/03) | 2012/03/04 |
| henrys | mvrhel:still around? | 06:47.16 |
| malc_ | tor8: hi, what's the easiest way to check if two bboxes are equal? | 13:38.25 |
| tor8 | malc_: I don't think there is one | 13:45.33 |
| malc_ | tor8: thought so, thanks | 13:46.40 |
| | tor8: was it you who played around with go's X11 module btw? | 13:49.37 |
| tor8 | malc_: I'm the original author of it, but I haven't exactly kept up with the changes | 13:50.12 |
| malc_ | tor8: oh.. it's just that i ditched glut and wrote my own (ocaml) stuff to do the same and while doing it hit some issues and was looking for answers in CLX and go.. the go one i've come across didn't have your name.. weird | 13:51.59 |
| tor8 | x-go-bindings is the one I wrote | 13:52.36 |
| | glx is a hairy mess | 13:52.45 |
| | xcb doesn't have support for gl last I checked | 13:52.58 |
| malc_ | glx is impossible to do with just X11 protocol.. took one night to figure out | 13:53.05 |
| tor8 | so you need to dig into libx11 and libglx no matter what | 13:53.17 |
| malc_ | aye | 13:53.24 |
| | learned the hard way | 13:53.34 |
| | things even work with cygwin and xquartz (for some definition of works) | 13:54.15 |
| | in any case, talking the protocol directly is liberating | 13:54.46 |
| mvrhel | henrys: I am here now | 15:13.32 |
| | another tiffsep with unencodable colors plus an error I see | 15:16.15 |
| henrys | right I just thought it best to give that one to you. | 15:26.25 |
| mvrhel | yes. I will start looking at these issues this week. | 15:27.16 |
| sebras | Robin_Watts: I had a quick look at your API-splitting patch, and I belive that fz_open_file(), fz_open_file_w() and fz_open_memory() should be in fitz.h | 15:44.59 |
| | not sure about fz_open_buffer() as it seems internal to me (do we need to expose fz_buffer at all? | 15:45.34 |
| | additionally fz_new_pixmap_with_data() and fz_new_pixmap_with_rect_and_data() should also be in fitz.h if I have understood tor8 correctly. | 15:45.58 |
| henrys | mvrhel:fwiw the error is that there are unencodable colors - the rangecheck comes from gdevtsep.c:1718 | 16:28.25 |
| Robin_Watts | sebras: Thanks. | 17:48.32 |
| | Pulling a couple of functions either way doesn't seem a huge change - the main thing is that you're both happy with the overall shape of it now. | 17:49.34 |
| mvrhel | thanks henrys: I may get a chance to look over this tonight | 18:10.37 |
| fiesh | Hi. I was wondering, but this has probably been suggested before, what about multi-page-view for mupdf? So that you can look at two or even more pages simultaneously. That's the one feature that I like about Acrobat Reader, you can display two pages of a PDF next to each other. Makes reading of scientific articles much much much easier. | 19:16.16 |
| Robin_Watts | The MuPDF core is easily capable of it. | 19:24.28 |
| | Our simple viewer app doesn't. | 19:24.57 |
| | but feel free to make it do so and submit a patch. | 19:25.09 |
| malc_ | Robin_Watts: i believe f86c02284c259b9034f324dffe76969efa8b2e42 broke patched rendering | 19:34.45 |
| Robin_Watts | malc_: How so? | 19:39.25 |
| malc_ | Robin_Watts: well, it's slow as hell | 19:40.16 |
| Robin_Watts | Well, it's possible that I've broken it in some way so that it redecodes on every use. | 19:41.28 |
| | but I can't immediately see how. | 19:41.34 |
| | Is it just that it's slow, or is rendering wrong? | 19:41.48 |
| malc_ | i'm verifying, the commit prior to that is fine.. | 19:42.00 |
| | it's painfully slow and i think memory usage is higher too | 19:42.23 |
| | yep.. definitely f86c02284c259b9034f324dffe76969efa8b2e42 | 19:43.30 |
| | and i'm on scale down path FWIW | 19:43.57 |
| | original image is 6395x4904, tile size i'm using in this test is 256x256 | 19:45.42 |
| Robin_Watts | malc_: Can't really talk about this too much now, but if you want to look, a good place would be in pdf/pdf_image.c in the pdf_image_get_pixmap function. | 19:47.04 |
| | That checks for finding tiles in the cache, picks a subsample range, decodes, and inserts them in the cache. | 19:47.31 |
| | I'd guess that you're failing to get cache hits. | 19:47.41 |
| malc_ | thanks | 19:47.50 |
| Robin_Watts | Some debugging in there might give me a clue. | 19:47.54 |
| malc_ | minor nit though, i'm not failing anything, you do | 19:48.09 |
| Robin_Watts | yes, indeed. | 19:52.08 |
| | I mean, in the way the code is being called in your application, we're failing to get cache hits. I'm not blaming you. | 19:52.31 |
| malc_ | okay.. i've increased store size from 128 to 256 and it's fast again.. | 19:52.36 |
| | it looks as if now images go to store, and mine is not big enough, correct? | 19:53.05 |
| Robin_Watts | could well be. | 19:53.42 |
| malc_ | what i meant to confirm is - prior to that commit images didn't go to store? | 19:54.18 |
| Robin_Watts | They would have gone to store, yes. but now we store both encoded and decoded images. | 19:56.57 |
| | Actually, that's not true. | 19:57.16 |
| malc_ | Aha, thanks | 19:57.16 |
| | oh | 19:57.19 |
| Robin_Watts | or maybe it is. | 19:57.21 |
| | yes, I think it is. | 19:57.27 |
| malc_ | the validity of the commit message i'm about to make is solely on your sholders | 19:58.23 |
| fiesh | Robin_Watts: ok, if there's no objections against such a patch I'll look into it | 20:54.05 |
| dromede | hi there | 21:42.01 |
| ghostbot | salut | 21:42.02 |
| dromede | any mupdf devs around? i have quick question | 21:42.17 |
| | i'm running mupdf compiled from latest git on an arm machine with a pxa270 SOC and a 16 bit display | 21:43.01 |
| | scrolling is very slow | 21:43.16 |
| | so i ran oprofile and it turns out that 90% of cpu time while scrolling is spent in ximage_convert_rgb555 | 21:43.47 |
| | so i was wondering if it's possible to make mupdf output 16 bit graphics directly? | 21:44.42 |
| tor8 | dromede: afraid not | 22:03.28 |
| dromede | so output is fixed at 32 bit ? | 22:03.51 |
| tor8 | yup. 16-bit is pretty rare these days too. | 22:04.11 |
| dromede | that's true | 22:04.18 |
| tor8 | 16-bit displays that is | 22:04.20 |
| dromede | it is an older device | 22:04.32 |
| | i'll try rewriting ximage_convert_rgb555 in asm | 22:05.14 |
| | i could use a good 32 > 16 bit conversion algorithm | 22:05.50 |
| | prefferably a parallel one | 22:06.15 |
| | Forward 1 day (to 2012/03/05)>>> | |
IRC Logs