| | <<<Back 1 day (to 2011/10/22) | 2011/10/23 |
| AlecTaylor | hi | 01:44.51 |
| | What version of libjpeg does MuPDF require? | 01:52.39 |
| | Getting a strange error from make in MuPDF...(I have done sudo apt-get install jbig2dec) - | 01:59.26 |
| | CC build/debug/filt_jbig2d.o | 01:59.30 |
| | fitz/filt_jbig2d.c:18:19: fatal error: jbig2.h: No such file or directory | 01:59.32 |
| | compilation terminated. | 01:59.34 |
| | make: *** [build/debug/filt_jbig2d.o] Error 1 | 01:59.35 |
| sebras | AlecTaylor: you have installed the jbig2dec userspace tools, but you need the library header files as well. try to install libjbig2dec0-dev | 02:26.44 |
| AlecTaylor | Thanks | 02:40.39 |
| vtorri | hey | 06:39.42 |
| ghostbot | niihau | 06:39.42 |
| vtorri | there are some optims for ARM | 06:39.53 |
| | will there be some optims using MMX, SSE* ? | 06:40.07 |
| mvrhel2 | there arlready are in ghostscript | 06:56.01 |
| vtorri | ho, sorry, in mupdf | 06:58.45 |
| | is pdf_getpagecount() replaced by pdf_count_pages() ? | 07:45.59 |
| | and pdf_find_page_object() by pdf_find_page_number() ? | 07:51.05 |
| | another question : does pdf_load_page() request the num of page starting from 0 and not 1 ? | 09:02.30 |
| | also, it seems that valgrind reports error with vfprintf, maybe because of fz_error | 09:22.09 |
| sebras | ghostbot: :-D ni hao ma? å¯æ¯ ä½ æ說 æ¼é³! æçååæ¯ sebras. | 09:32.16 |
| vtorri | too bad there is no ML | 10:14.07 |
| | tor8: hey | 11:07.43 |
| tor8 | hi | 11:08.03 |
| vtorri | tor8: i have several questions about mupdf :) | 11:08.28 |
| | tor8: will there be some optims using MMX, SSE* ? (currently, only ARM asm) | 11:08.50 |
| tor8 | okay. | 11:09.16 |
| | we're generally not fond of platform specific code, but the gcc arm compiler produces terrible code, bad enough that robin watts likes reimplementing important inner loops in arm asm. | 11:10.13 |
| vtorri | ha, ok | 11:10.26 |
| | tor8: about api changes, is pdf_getpagecount() replaced by pdf_count_pages() ? | 11:11.01 |
| tor8 | we have to weigh in the added maintenance cost for every feature we add, and duplicated functionality adds a lot of burden | 11:11.05 |
| vtorri | of course | 11:11.29 |
| tor8 | vtorri: all functions were renamed a long time ago when we changed naming conventions. we used a sed script for batch renaming, it's in "scripts/rename.sed" | 11:12.03 |
| vtorri | not sufficient | 11:12.37 |
| | usually, it's a rename like: | 11:12.45 |
| | fz_nom1nom2 ---> fz_nom1_nom2 | 11:13.06 |
| | i've looked at the script | 11:13.14 |
| tor8 | yeah. there have been further tweaks after that, which may not be reflected in the script. | 11:13.40 |
| vtorri | that's why i ask, as the is no doc... | 11:14.05 |
| | there* | 11:14.09 |
| tor8 | git log is the doc ;) | 11:14.21 |
| vtorri | noo, don't react like ffmpeg users | 11:14.31 |
| | oups | 11:14.37 |
| | devs | 11:14.39 |
| | tor8: does pdf_load_page() request the num of page starting from 0 and not 1 (like it was before) ? | 11:15.10 |
| | ti seems so according to my tests | 11:15.31 |
| tor8 | we made it zero-based when we changed the api calls for loading a page | 11:16.01 |
| vtorri | ok | 11:16.10 |
| | now, other kind of questions: | 11:16.24 |
| tor8 | which we did when we added muxps, which had a more consistent api for that | 11:16.29 |
| vtorri | valgrind reports memory reads errors | 11:16.35 |
| | about vfprintf | 11:16.49 |
| tor8 | hmm, that's not good. we should be valgrind clean :( | 11:16.58 |
| vtorri | i think it's about error management in fitz | 11:17.01 |
| tor8 | does it report the errors always, or just on specific files? | 11:17.35 |
| vtorri | tor8: http://codepad.org/bnGWf6rC | 11:17.56 |
| | that's all | 11:18.12 |
| tor8 | sometimes libc does stupid things that trigger valgrind | 11:18.17 |
| vtorri | yes | 11:18.27 |
| | dlopen for example | 11:18.33 |
| tor8 | a while back, 64-bit compiles were completely unusable under valgrind because they were using sse-optimized strcmp and friends which triggered UMR:s absolutely everywhere | 11:18.57 |
| vtorri | the only places where vfprintf is used is in mupdf source code | 11:19.38 |
| | that's why i think that it's in mupdf | 11:19.51 |
| | in ./draw/draw_scale.c | 11:20.56 |
| tor8 | the stack trace in that paste shows it coming from main()? | 11:21.04 |
| vtorri | yes | 11:21.14 |
| | i don't understand | 11:21.18 |
| | i build with -g | 11:21.32 |
| tor8 | do you call any printf function in your main? | 11:21.37 |
| Robin_Watts | vtorri: We have a new branch open for mupdf, "context", in which we are adding a context throughout mupdf to a) remove global vars, and b) handle memory errors better. | 11:21.43 |
| vtorri | so normally valgrind has all the needed informations | 11:21.44 |
| | robin_watts : ok | 11:22.13 |
| | last question : | 11:22.35 |
| Robin_Watts | but I can't see, based on that paste, how you can blame draw/draw_scale.c for that. | 11:22.38 |
| vtorri | robin_watts : well, i just use printf, like usual | 11:23.18 |
| | and not vfprintf explicitely | 11:23.29 |
| tor8 | printf may very well call vfprintf internally | 11:23.32 |
| vtorri | yes | 11:23.36 |
| | i know | 11:23.38 |
| | but i display strings, integers, etc.. | 11:23.50 |
| | no gcc warnings about my uses | 11:23.57 |
| | that's why i think that it's not from my code | 11:24.08 |
| | the only other *printf use that I can see is in draw.c | 11:24.33 |
| Robin_Watts | but only in debug cases, right? | 11:24.48 |
| vtorri | well, there are fprintf calls in mupdf too | 11:24.58 |
| tor8 | do me a favor: remove your printf and see if valgrind still makes an error? | 11:24.59 |
| Robin_Watts | goes for run. | 11:25.02 |
| vtorri | tor8: ok | 11:25.06 |
| | same | 11:27.58 |
| | i can try to isolate where the error is called | 11:28.11 |
| | a wait | 11:28.21 |
| | no | 11:28.39 |
| | it's indeed my code | 11:28.48 |
| | damn | 11:28.51 |
| | a printf("%d", 1); is throwing an error | 11:29.39 |
| | in valgrind | 11:29.54 |
| | it's crazy | 11:30.15 |
| | sorry for that noise | 11:30.35 |
| | tor8: last question : | 11:30.41 |
| | it's about optimisation of the rendering | 11:30.54 |
| | sebras told me that when i have the display list, i can render other pages without calling pdf_load_page and pdf_run_page | 11:32.02 |
| tor8 | yeah. | 11:32.15 |
| vtorri | i have cached the display list | 11:32.22 |
| | so how can I do that ? | 11:32.27 |
| tor8 | pdf_load_page will load the page info and contents into a buffer. pdf_run_page will interpret the contents in that buffer with the given device. | 11:33.07 |
| | if you just want to draw the page once, you call pdf_run_page with a "draw device" to render into a pixmap | 11:33.45 |
| | if you're going to be drawing the same page many times, you can call pdf_run_page with a "display list recording device" which records all the device calls into a linked list | 11:34.19 |
| | then you can execute that recording on another device, without having to do the expensive parsing | 11:34.43 |
| vtorri | drawing the page many times like displaying the current page, and a snapshot elsewhere (for example) ? | 11:35.24 |
| tor8 | for example. or redrawing it when you zoom in. or running the text extraction device. | 11:35.53 |
| | the display list will save you the need to reparse the content stream. | 11:36.10 |
| | at the cost of more memory, of course. so it's a trade off -- more performance at the cost of more memory. | 11:36.42 |
| vtorri | of course | 11:36.51 |
| tor8 | in practice, parsing the page is a fairly insignificant cost to pay compared with just drawing a single image. | 11:37.25 |
| vtorri | i'm wondering howi can integrate that in my framework (that is supporting several kind of rendering) | 11:37.38 |
| | well, one of the use of my lib is rendering on embedded devices | 11:38.19 |
| tor8 | how did you do it before? | 11:39.51 |
| vtorri | i created the list | 11:40.02 |
| | then the dev | 11:40.07 |
| | pdf_run_page | 11:40.22 |
| | free dev | 11:40.24 |
| | free list | 11:40.27 |
| tor8 | right. if you only use the list once, it's usually better to just skip it. | 11:41.36 |
| vtorri | now, i cache the display list | 11:41.38 |
| tor8 | does your framework have a "page" object which is expected to be heavyweight with a lot of data? | 11:43.09 |
| vtorri | yes | 11:43.18 |
| tor8 | well, stick the mediabox and display list in there then :) | 11:43.37 |
| vtorri | if you want to have a look | 11:43.56 |
| | http://trac.enlightenment.org/e/browser/trunk/PROTO/eyesight/src/modules/pdf/eyesight_pdf_mupdf.h | 11:43.59 |
| | http://trac.enlightenment.org/e/browser/trunk/PROTO/eyesight/src/modules/pdf/eyesight_pdf_mupdf.c | 11:44.02 |
| tor8 | what you have there looks okay. | 11:46.33 |
| | you can probably free the pdf_page object as soon as you've extracted the links, mediabox and created the display list | 11:47.00 |
| | no need to hang on to it after that -- since it does contain the unparsed page contents in a buffer | 11:47.23 |
| vtorri | ok | 11:48.44 |
| tor8 | and since you're not using the text you can skip running the text device altogether | 11:48.55 |
| vtorri | "not using the text" <--- what does it mean ? | 11:49.28 |
| tor8 | you call fz_free_text_span(text); just after you create it | 11:49.47 |
| | lines 724..729 | 11:50.02 |
| vtorri | ha | 11:50.57 |
| tor8 | and as you say in your FIXME, call fz_new_pixmap_with_data is going to save you a big memcpy | 11:51.11 |
| vtorri | with the text, I can do some search ? | 11:51.14 |
| tor8 | yes. search and copy/paste. | 11:51.24 |
| vtorri | ok | 11:51.31 |
| tor8 | but the text api is about to change | 11:51.38 |
| vtorri | i'm not used with mupdf yet | 11:51.46 |
| | arg ! | 11:51.51 |
| | so i'll wiat | 11:51.54 |
| tor8 | I have a "text" branch which adds a lot more information to the extracted text | 11:52.00 |
| vtorri | ok | 11:52.08 |
| tor8 | but I've got a higher priority project I need to take care of before I can wrap up that branch and merge it | 11:52.19 |
| vtorri | line 726, about the fixme | 11:52.23 |
| | are they correct ? | 11:52.37 |
| | i don't know if fz_infinite_bbox is the correct box to use | 11:52.55 |
| sebras | tor8: vtorri asked about changing functions that today take ints to explicitly take named enums. see e.g. pdf_has_permission) | 11:53.01 |
| vtorri | ha right | 11:53.14 |
| tor8 | well, I'd pass fz_identity instead so you can reuse the text objects with different zoom levels | 11:53.17 |
| | fz_infinite_bbox is the right thing to pass | 11:53.25 |
| vtorri | tor8: fz_identity instead of ctm ? | 11:53.48 |
| tor8 | pdf_has_permission takes a bitmask doesn't it? | 11:54.05 |
| | there is an enum which defines bitmasks, PDF_PERM_PRINT and friends | 11:54.37 |
| | vtorri: yes. | 11:54.44 |
| vtorri | PDF_PERM_* are bitsmasks | 11:54.46 |
| sebras | tor8: it does, but the proto is pdf_has_permission(pdf_xref *, int) instead fo pdf_has_permission(pdf_xref *, enum pdf_perms) | 11:55.01 |
| vtorri | it would be clearer for the user if the enum had a name | 11:55.28 |
| | and pdf_has_permission use that type instead of just an int | 11:55.55 |
| tor8 | but an enum wouldn't allow things like: p = PDF_PERM_PRINT | PDF_PERM_COPY; if (pdf_has_permission(p) == p) | 11:56.13 |
| | otoh, the code doesn't allow that anyway I see now | 11:56.37 |
| vtorri | an enum is an int | 11:57.05 |
| | so you could do that | 11:57.19 |
| tor8 | I don't like enum types, much like I don't like const. | 11:58.01 |
| vtorri | :) | 11:58.11 |
| | unfortunately, i have one more question :) | 11:58.35 |
| sebras | tor8: const tends to self-propagate in a way that enums do not though... | 11:58.39 |
| vtorri | with my application test of my lib, i can go to next and previous page | 11:59.16 |
| | then there is a rendering bug | 11:59.26 |
| sebras | tor8: why would your example not work? the PDF_PERM have correct values, if "int p" then your example ought to work, no..? | 11:59.34 |
| vtorri | i display the 1st page | 11:59.40 |
| | i display the 2nd page (which is empty) | 11:59.54 |
| tor8 | sebras: enum types are distinct from ints. what's the result of arithmetic on enums? | 11:59.56 |
| vtorri | then i go back to the 1st page | 12:00.02 |
| | the rendering of the 1st page, at the second time, is slightly shifted | 12:00.41 |
| | by one pixel or so | 12:00.46 |
| tor8 | vtorri: hang on a minute. line 583 -- are you reusing the same display list for all pages? | 12:01.09 |
| vtorri | compared to the 1st time the 1st page is displayed | 12:01.16 |
| | tor8: yes | 12:01.35 |
| tor8 | you can't do that. | 12:01.44 |
| vtorri | it seems it is bad :) | 12:01.45 |
| | ok | 12:02.12 |
| tor8 | if you pdf_run_page many pages on the same display list, their contents will be appended onto each other | 12:02.13 |
| vtorri | so when I should create the display list, and when i should free it ? | 12:02.34 |
| tor8 | create it when you load the page | 12:02.46 |
| | free it when you're done with the page | 12:02.50 |
| vtorri | when i finish the rendering ? | 12:03.25 |
| tor8 | are you going to render the same page more than once? | 12:05.20 |
| sebras | vtorri: e.g. if the user asks eyesight to go back to a previous page. | 12:07.33 |
| tor8 | vtorri: what will happen when the viewer changes the zoom level? | 12:08.23 |
| sebras | vtorri: or pans on a zoomed-in page? | 12:09.06 |
| | vtorri: if you at any of these points ask mupdf to re-parse and re-render the entire page then eyesight will appear to be slow. | 12:09.40 |
| vtorri | tor8: about rendering the same page, it depends | 12:10.26 |
| | it can, yes | 12:10.33 |
| tor8 | well, if it can you may want to hang on to the display list a bit longer | 12:10.53 |
| sebras | vtorri: so what you should do is to ask mupdf to parse the page, save the display list and then execute the display list to render the page. if the user e.g. zooms in then you just re-execute the display list again. some time later you free the display list. | 12:10.55 |
| tor8 | some time later would typically be when you change page | 12:11.14 |
| vtorri | ok | 12:11.23 |
| tor8 | so in em_set_page() { free-old-display-list; create-new-display-list; run-page; } | 12:11.43 |
| sebras | tor8: would it make sense to keep it around for longer than that? say to keep the last 5 viewed page's display list's around? | 12:11.58 |
| tor8 | and in em_render_page() { create-new-pixmap; execute-display-list; } | 12:12.00 |
| | sebras: no, I wouldn't do that. wastes too much memory :) | 12:12.17 |
| sebras | tor8: I'm unsure of how much memory those lists occupy... | 12:12.24 |
| vtorri | tor8: ok | 12:12.26 |
| | that's what i thout | 12:12.30 |
| tor8 | don't forget that a display list holds on to all images and their data. | 12:12.36 |
| vtorri | tought | 12:12.37 |
| | freeing it when i change the page | 12:12.46 |
| tor8 | sebras, Robin_Watts: we should probably tweak the pdf_store now that it's more of a cache than a storage area for preloaded resources, so we don't need to hold on to big images for the duration of the rendering. | 12:13.38 |
| sebras | tor8: what about the size of a rendered pixmap versus a display list? I guess the size depends on if there are many images on the page that are being scaled down... | 12:13.39 |
| tor8 | sebras: rendering will always be more expensive | 12:14.12 |
| | you will always gain a lot by caching a finished pixmap | 12:14.25 |
| sebras | tor8: sure, but I was thinking about memory requirements... | 12:14.29 |
| tor8 | the gains from caching a display list are more nebulous | 12:14.40 |
| sebras | tor8: pixmap >> displaylist or pixmap << displaylist or "it depends"? | 12:14.52 |
| vtorri | tor8: thanks for the help :) | 12:14.57 |
| tor8 | sebras: it depends on the page contents :) | 12:15.04 |
| | for plain text pages, pixmap >>>>>>> displaylist | 12:15.15 |
| | for pages with high res images, it depends | 12:15.51 |
| | vtorri: the code in apps/pdfapp.c isn't the cleanest, but it does provide an example of what you're trying to do | 12:16.22 |
| vtorri | ok | 12:16.32 |
| tor8 | we do have plans to make a higher level, easier to use api for viewer applications | 12:16.40 |
| vtorri | i looked at pdfdraw.c | 12:16.41 |
| | as i want to twweak the rendering, maybe i'll keep the low level api | 12:17.12 |
| | even if it changes | 12:17.18 |
| | poppler did that, by adding glib, qt and c++ frontends, but i didn't like them | 12:17.38 |
| | they "force" a use of the library | 12:17.47 |
| tor8 | vtorri: yeah, we will always let you use the more "toolbox" level of api:s | 12:18.07 |
| | the new api we're thinking of will mainly abstract the differences between xps and pdf, and remove some of the busywork you have to do to render a page | 12:18.46 |
| vtorri | ok | 12:19.51 |
| tor8 | the old way of doing things will still work, so don't sweat it yet | 12:20.10 |
| vtorri | :) | 12:20.24 |
| | i like old ways of things :) | 12:20.34 |
| | i have to look at how xps is rendered now :) | 12:21.14 |
| | fortunately, there is an xpsdraw.c :) | 12:21.55 |
| LaoLang_cool | hi, any news on mupdf on phone? | 12:45.17 |
| | which phone's platform is best for *nix geek | 12:45.50 |
| | maemo, webos, andriod, or others? | 12:46.08 |
| vtorri | tizen ! | 12:49.53 |
| | as it will use the EFL :p | 12:50.03 |
| LaoLang_cool | wow! | 12:53.24 |
| | impressive | 12:53.28 |
| Robin_Watts | tor8: I agree about the store being a cache. | 12:58.49 |
| | I think we always put stuff into the cache, we just evict it LRU style as we run out of memory. | 12:59.10 |
| | This means find becomes 'claim' and we need a 'release'. | 13:00.30 |
| | And 'add' becomes 'encache' (puts something in, and leaves it claimed) | 13:00.55 |
| sebras | vtorri: oh, I didn't know tizen was to use efl... | 13:07.06 |
| | Robin_Watts: once/if we go multithreading then I guess pdf_cache would need some locking too. | 13:08.30 |
| vtorri | sebras: it was announce (unofficially, but publicly) in september | 13:08.57 |
| sebras | vtorri: right. having been employed in the telecom industry until yesterday you would have been led to believe that I would know that. unfortunately my former employer is not at the, let's say... latest technological edge. | 13:10.18 |
| vtorri | :) | 13:16.29 |
| LaoLang_cool | will mupdf port into n900 (maemo)? | 13:21.41 |
| sebras | LaoLang_cool: there is currently no planned port to moblin/maemo/meego/meltemi. porting mupdf to those platforms may be possible, but one would likely have to write a new viewer for each as they have(?) different GUI-frameworks. | 13:28.30 |
| LaoLang_cool | sebras: too bad there isn't an uniform GUI, the world is spliting | 13:29.43 |
| borei | hi all | 19:58.23 |
| | im stuck with cups and ghostscript | 19:58.47 |
| | gs[6519]: segfault at 4aeea9c ip 000000000086e465 sp 00007fff32599560 error 4 in gs[400000+793000] | 19:59.00 |
| | can't find the reason | 19:59.18 |
| | gs version is 9.04 | 19:59.27 |
| | cups 1.5.0 | 19:59.33 |
| | does anybody has idea ? | 20:00.11 |
| sebras | borei: it's sunday evening and the regular ghostscript crowd are probably resting a bit. | 20:10.13 |
| | borei: if you return in 10hours or so I'm sure they'll be around and help you. | 20:10.47 |
| borei | :-), thanks sebras | 20:11.43 |
| sebras | np. | 20:12.19 |
| ray_laptop | borei: there were a couple of cups fixes recently | 20:23.08 |
| | borei: I fixed one for bug 692568 (cups with RGBW mode) that happened when using banded (clist) mode | 20:25.29 |
| | borei: and bug 691922 was after the 9.04 release | 20:34.40 |
| borei | hey, ray_laptop | 20:39.46 |
| | i just downgraded to gs 9.02 - started to wrok | 20:40.04 |
| | that issue defenitelly with gs | 20:40.18 |
| | not cup | 20:40.21 |
| | cups | 20:40.22 |
| ray_laptop | borei: if you can retest with the git 'master' current version, we'd appreciate it. Then you can open a bug if it still exists (we'd need the command line options and the input file) | 22:57.10 |
| LaoLang_cool | weechat.look.buffer_notify_default = message | 23:49.00 |
| | oh, sorry for noice | 23:49.08 |
| | Forward 1 day (to 2011/10/24)>>> | |
IRC Logs