Created attachment 385820 [details] A simple OOo presentation with an included image Description of problem: When showing a presentation in presentation mode frames appear around all images. No frames appear around the images in edit mode Version-Release number of selected component (if applicable): 3.1.1-19.14.fc12 How reproducible: always Steps to Reproduce: 1. create a new, blank presentation 2. on a black slide, insert and image. no frame should appear around the image 3. go to presentation mode (F5) and a frame appears around the image Actual results: frame appears around image Expected results: the presentation mode slide should look the same as when we are in the editing mode. It does not. A frame appears in presentation mode but not edit mode. Additional info: image was PNG format. Intel graphics.
Created attachment 385821 [details] a screenshot of openoffice with the attached presentation when in edit mode
Created attachment 385822 [details] a screenshot of openoffice with the attached presentation when in presentation mode -- note the frame around the image
I've attached a sample presentation and screenshots when in edit mode and in presentation mode. You can clearly see that no frame appears around the image in edit mode, but a frame appears around the image when in presentation mode.
Turning off hardware acceleration in Tools -> Options -> OpenOffice.org / View makes the border go away. But this does not seem to be a long term solution for a large presentation with many graphics objects. This bug also seems to be discussed here: http://user.services.openoffice.org/en/forum/viewtopic.php?f=10&t=13950
Sounds similar to bug 512355. Maybe there is the same issue with bitmaps. Not reproducible with my ATI card, though.
I can see it on my i915, looks similar to that previous subpixel thing
Created attachment 385965 [details] standalone demo standalone demo gcc grayborder.c `pkg-config --cflags --libs cairo-xlib`
caolanm->dtardon: Can you try the above demo on your ATI and see if you get a gray or black border around this. Results to date are: F-11: nv_drv: cairo-1.8.8-1.fc11.i586, no border (i.e. pass) F-12: vesa: cairo-1.8.8-3.fc12.i686, partial border (i.e. fail) F-13: nouveau: cairo-1.8.8-3.fc12.x86_64, full border (i.e. fail)
dtardon->caolan: sure. F-13: radeon: cairo-1.8.8-3.fc12.x86_64, no border (i.e. pass)
caolanm->behdad: Could you give us some help here and have a look at the standalone demo above. cairo_matrix_init (&matx, 1.5, 0.0, 0.0, 1.5, 0.0, 0.0); cairo_set_matrix( cr, &matx); cairo_set_source_surface( cr, source, 0, 0 ); /*where source is a blank image*/ cairo_paint( cr ); gives us some borders around the image sometimes. Is there something client side we can do about that ?
Looks like a driver bug. Doesn't happen for me here. Suggest you chase the X guys. As for workarounds, pixel-aligning the scaled image definitely would help. Other options may be using EXTEND_PAD and using a rectangle around the image. Not sure about the performance implications of that.
Let move it over to X then, with i945 I also have a gray border in F-13.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf, if available), output of the dmesg command, system log (/var/log/messages), and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 398009 [details] dmesg
Created attachment 398012 [details] /var/log/messages
Created attachment 398013 [details] Xorg.0.log
Created attachment 398014 [details] xdpyinfo for resolution depth etc
no xorg.conf in my case. xorg-x11-drv-intel-2.10.0-4.fc13.i686 pixman-0.17.8-1.fc13.i686 Also visible with xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.x86_64 pixman-0.17.8-1.fc14.i686
Created attachment 398016 [details] what my test case looks like for me on intel
Created attachment 398017 [details] and how it looks in nouveau
This could be really it. Cannot reproduce on ATI Radeon X1400, with pixman-0.16.6-1.fc12.x86_64 and xorg-x11-drv-ati-6.13.0-0.20.20091221git4b05c47ac.fc12.x86_64 Reassigning to pixman component for further investigation.
(In reply to comment #13) > Thanks for the bug report. We have reviewed the information you have provided > above, and there is some additional information we require that will be helpful > in our diagnosis of this issue. > > Please attach your X server config file (/etc/X11/xorg.conf, if available), > output of the dmesg command, system log (/var/log/messages), and X server log > file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file > attachments using the bugzilla file attachment link above. > > We will review this issue again once you've had a chance to attach this > information. Reporter, forget about the logs, could you please give us output of these commands? rpm -qa xorg-x11-drv-\* xorg-x11-server-Xorg pixman and lspci |grep VGA Thank you
lspci |grep VGA 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) xorg-x11-drv-fbdev-0.4.1-3.fc13.i686 pixman-0.17.8-1.fc13.i686 xorg-x11-drv-nv-2.1.15-5.fc13.i686 xorg-x11-drv-openchrome-0.2.904-2.fc13.i686 xorg-x11-drv-s3virge-1.10.4-2.fc13.i686 xorg-x11-drv-r128-6.8.1-3.fc13.i686 xorg-x11-drv-mach64-6.8.2-2.fc13.i686 xorg-x11-drv-neomagic-1.2.4-3.fc13.i686 xorg-x11-drv-synaptics-1.2.1-3.fc13.i686 xorg-x11-drv-vmware-10.16.7-3.fc13.i686 xorg-x11-drv-acecad-1.4.0-3.fc13.i686 xorg-x11-drv-penmount-1.4.0-6.fc13.i686 xorg-x11-drv-mouse-1.5.0-4.fc13.i686 xorg-x11-drv-rendition-4.2.2-5.fc13.i686 xorg-x11-drv-geode-2.11.4.1-2.fc13.i686 xorg-x11-drv-hyperpen-1.3.0-4.fc13.i686 xorg-x11-drv-dummy-0.3.3-2.fc13.i686 xorg-x11-drv-apm-1.2.2-1.fc12.i686 xorg-x11-drv-siliconmotion-1.7.3-3.20100122.fc13.i686 xorg-x11-drv-tdfx-1.4.3-2.fc13.i686 xorg-x11-drv-radeonhd-1.3.0-5.4.20100210git.fc13.i686 xorg-x11-drv-sis-0.10.2-2.fc13.i686 xorg-x11-drv-glint-1.2.4-2.fc13.i686 xorg-x11-drv-intel-2.10.0-4.fc13.i686 xorg-x11-drv-wacom-0.10.4-5.fc13.i686 xorg-x11-drv-voodoo-1.2.3-2.fc13.i686 xorg-x11-drv-fpit-1.3.0-8.fc13.i686 xorg-x11-drv-evdev-2.3.99-2.20100108.fc13.i686 xorg-x11-drv-mutouch-1.2.1-6.fc13.i686 xorg-x11-drv-i740-1.3.2-2.fc13.i686 xorg-x11-drv-i128-1.3.3-2.fc13.i686 xorg-x11-drv-vesa-2.2.1-2.fc13.i686 xorg-x11-drv-elographics-1.2.3-6.fc13.i686 xorg-x11-drv-ati-6.13.0-0.23.20100219gite68d3a389.fc13.i686 xorg-x11-drv-void-1.3.0-5.fc13.i686 xorg-x11-drv-trident-1.3.3-2.fc13.i686 xorg-x11-drv-vmmouse-12.6.6-1.fc13.i686 xorg-x11-drv-sisusb-0.9.3-2.fc13.i686 xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.i686 xorg-x11-drv-cirrus-1.3.2-2.fc13.i686 xorg-x11-drv-keyboard-1.4.0-4.fc13.i686 xorg-x11-server-Xorg-1.7.99.901-8.20100223.fc13.i686 xorg-x11-drv-savage-2.3.1-2.fc13.i686 xorg-x11-drv-aiptek-1.3.0-3.fc13.i686 xorg-x11-drv-v4l-0.2.0-4.fc13.1.i686 xorg-x11-drv-ast-0.89.9-1.fc12.i686 xorg-x11-drv-mga-1.4.11-2.fc13.i686
I can't reproduce this with xorg-x11-drv-nouveau-0.0.15-20.20091105gite1c2efd.fc12.i686 xorg-x11-server-Xorg-1.7.5-5.fc12.i686 and pixman 0.17.10.
Created attachment 438547 [details] A fix The padding did the trick - can anybody enlighten me why this suddenly started to be necessary? Older drivers plain ignoring border treatment? Other than that, let's add newer nvidia versions to the list of susceptible implementations.
cmc->thb: Is that workaround committed to upstream OOo already ?
@cmc: nah, just pushed to ooo-build as of yesterday. Am reasonably certain it does no harm (checked it on both broken and working xorg versions), but that does not mean much - at any rate, feel free to grab it, if you have an upstream CWS at hand.
Note that as far as I know, the padding is not a workaround. If the code works without the EXTEND_PAD, that's a bug in the driver!
caolanm->behdad: What do you mean ?, that the case where we *don't* get a frame around the image is a driver bug ? Or that the case where we *do* get a frame is a driver bug. cmc->thb: I see a suspicious comment in cairo_canvashelper.cxx of a workaround for "random data on the image right", do you know how to reproduce that other problem. Maybe its the same problem in another guise.
@cmc: played with that line even before trying the PAD thing, I believe it's unrelated & indeed exposed an old bug. Generally, the width of the pattern blit is fractional, anyway, so adding .5 is not changing matters ...
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.