Re: ggv/gpdf and evince
Il giorno gio, 09/06/2005 alle 13.08 -0400, Luis Villa ha scritto: I think there seems to be a very strong consensus that ggv/gpdf should be replaced by evince in 2.12. Does anyone object to me going ahead and removing them from the jhbuild moduleset and adding evince? Wait. There are some troubles with poppler+cairo on head :-( I didn't yet report them, 'cause I'm still performing some tests and collecting info on not well behaving PDF files, but it seems there is a performance regression in recent CVS builds. The most critical PDF file is this[1] introduction to signal processing in Scilab (and maybe all PDFs from the same location): it locks the poppler benckmark application at page 2 (!!!) and leaves the evince view empty. There are some slowness with some PDFs[2] from Apple website[3] too. I _suppose_ it could be a cairo issue, because I remember that all works fine in pre cairo-0.5.0 days. BTW it seems that gpdf too has a wrong rendering on [1]: all math formulas disappear (see i.e. page 16 or 19) and some graphs are simply wrong (see i.e. page 18): only xpdf (3.00) works fine in this file :-| And evince+poppler_splash of course. Moreover it seems that evince suffers for a slow re-rendering on resize that you can't feel in gpdf. With and without poppler's cairo output. Please note that I think we should include evince in GNOME, replacing gpdf and ggv. I'm only saying that maybe is better disable by now poppler's cairo backend: this will produce sometimes a less sexy rendering, but it's fast and with no faults. As attachment there are my records about poppler benchmarks: I'll report them on poppler bugzilla. [1] ftp://ftp.inria.fr/INRIA/Scilab/documentation/pdf/signal.pdf [2] http://images.apple.com/server/pdfs/Workgroup_Manager_TB_v10.4.pdf [4] http://www.apple.com/server/resources/ Poppler Benchmarks Poppler 0.3.2 (cairo 0.5.0) Document|Pages |Size |Real |User |Sys| - PostScript Language |772|3.7MB |48.38 |21.43 |20.43 | Reference Manual| | | | | | - Signal Processing with Scilab |205|1.3MB |137.46 |71.07 |57.39 | - Time Out|161|1.3MB |6.36 |3.81 |1.48 | - 101 GNOME things|90 |1.8MB |58.53 |47.36 |1.82 | - OSX Workgroup Manager |6 |316KB |1.51 |0.77 |0.24 | Poppler HEAD (cairo HEAD) on 2005-06-07 Document|Pages |Size |Real |User |Sys| - PostScript Language |772|3.7MB |45.65 |22.66 |19.81 | Reference Manual| | | | | | - Signal Processing with Scilab |205|1.3MB |* |* |* | - Time Out|161|1.3MB |6.27 |4.10 |1.49 | - 101 GNOME things|90 |1.8MB |58.02 |53.46 |1.80 | - OSX Workgroup Manager |6 |316KB |7.84 |7.05 |0.32 | Poppler HEAD (only Splash) on 2005-06-07 Document|Pages |Size |Real |User |Sys| - PostScript Language |772|3.7MB |66.05 |42.14 |20.01 | Reference Manual| | | | | | - Signal Processing with Scilab |205|1.3MB |20.11 |10.78 |7.95 | - Time Out|161|1.3MB |16.70 |14.07 |1.56 | - 101 GNOME things|90 |1.8MB |13.10 |11.06 |1.15 | - OSX Workgroup Manager |6 |316KB |1.54 |0.61 |0.23 | * Still rendering page 2 after about 3 minutes :-((( Killed. top says: PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 25 0 225m 190m 7608 R 84.1 76.2 2:59.87 benchmark Some info and notes about test suite * PLRM PDF version 1.1 A complex document, but well written: Evince don't
Re: ggv/gpdf and evince
On 6/10/05, Kristian Høgsberg [EMAIL PROTECTED] wrote: Please note that I think we should include evince in GNOME, replacing gpdf and ggv. I'm only saying that maybe is better disable by now poppler's cairo backend: this will produce sometimes a less sexy rendering, but it's fast and with no faults. As Marco points out, we have the possibility to bail out and re-enable the splash backend at any time, should we decide that the cairo backend is not ready. In the meantime, I'd like to enable the cairo backend by default so it gets a lot of testing. People are already using poppler with cairo and logging bugs about slow PDFs or incorrect rendering, and the current cvs head has improved much based on those reports already. I'd love to see more of this so we can close the gap between the cairo backend and the splash backend and hopefully make cairo itself faster in the process. With my testing hat on, I couldn't agree more. :) I assume you mean make it the default in the next evince release? Or would you like someone to add configure arguments to the jhbuild moduleset? BTW, Nagappan- does LDTP have any timed testing capabilities so it can be used for performance testing? Seems like evince and some of the other things switching to cairo would be a great target for that if LDTP has the capability. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ggv/gpdf and evince
Luis Villa [EMAIL PROTECTED] writes: On 6/10/05, Kristian Hgsberg [EMAIL PROTECTED] wrote: With my testing hat on, I couldn't agree more. :) I assume you mean make it the default in the next evince release? Or would you like someone to add configure arguments to the jhbuild moduleset? poppler already builds w/ cairo by default if it finds it. Just adding the dependency on cairo in jhbuild should be sufficient. Thanks, -Jonathan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ggv/gpdf and evince
Luis Villa wrote: On 6/10/05, Kristian Høgsberg [EMAIL PROTECTED] wrote: Please note that I think we should include evince in GNOME, replacing gpdf and ggv. I'm only saying that maybe is better disable by now poppler's cairo backend: this will produce sometimes a less sexy rendering, but it's fast and with no faults. As Marco points out, we have the possibility to bail out and re-enable the splash backend at any time, should we decide that the cairo backend is not ready. In the meantime, I'd like to enable the cairo backend by default so it gets a lot of testing. People are already using poppler with cairo and logging bugs about slow PDFs or incorrect rendering, and the current cvs head has improved much based on those reports already. I'd love to see more of this so we can close the gap between the cairo backend and the splash backend and hopefully make cairo itself faster in the process. With my testing hat on, I couldn't agree more. :) I assume you mean make it the default in the next evince release? Or would you like someone to add configure arguments to the jhbuild moduleset? It shouldn't be necessary to do anything -- the backend choice is in poppler at configure time. If cairo = 0.5 is available, poppler will default to the cairo backend. I was basically just arguing that we shouldn't switch jhbuild to the splash backend. cheers, Kristian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ggv/gpdf and evince
On 10 Jun 2005 15:33:58 -0400, Jonathan Blandford [EMAIL PROTECTED] wrote: Luis Villa [EMAIL PROTECTED] writes: On 6/10/05, Kristian Høgsberg [EMAIL PROTECTED] wrote: With my testing hat on, I couldn't agree more. :) I assume you mean make it the default in the next evince release? Or would you like someone to add configure arguments to the jhbuild moduleset? poppler already builds w/ cairo by default if it finds it. Just adding the dependency on cairo in jhbuild should be sufficient. OK. ATM jhbuilt gtk requires cairo, so evince shouldn't need any changes. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
ggv/gpdf and evince
I think there seems to be a very strong consensus that ggv/gpdf should be replaced by evince in 2.12. Does anyone object to me going ahead and removing them from the jhbuild moduleset and adding evince? Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ggv/gpdf and evince
Luis Villa [EMAIL PROTECTED] writes: I think there seems to be a very strong consensus that ggv/gpdf should be replaced by evince in 2.12. Does anyone object to me going ahead and removing them from the jhbuild moduleset and adding evince? Go for it. -Jonathan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
