Apache OpenOffice (AOO) Bugzilla – Issue 81092
DirectX support for canvas not available in all windows
Last modified: 2017-05-20 10:48:17 UTC
According to THB DirectX support (on Windows) for the canvas is available only in the first window that requests it. This prevents e.g. antialiasing for all but one window. Furthermore, in case of the presenter view, the first window might be not the primary slide show view. The result would be missing antialiasing and decreased performance in the primary slide show view.
Mostly done.
Retargetted surrounding CWS.
Moved to successor CWS presenterscreen.
Not fixed, but worked around for in CWS canvas05. Everybody except main slideshow should request a gdipluscanvas, which does not show the mentioned contention on the DXDevice (because it does not use DX at all).
@af: please verify in CWS canvas05, if this is acceptable - if not, we've got to move this issue to 3.1
At the moment I am using a com.sun.star.rendering.VCLCanvas for the presenter console extension and am happy with it (not too fast but it works). Switching now to a gdipluscanvas does not seem to be a good idea for three reasons: 1) We are too close to the release of OOo 3.0 for making such a big change with all its potential problems. 2) gdipluscanvas sounds like being platform dependent. I really would not like to take care of sorting out which canvas to use depending on the platform in the extension or its supporting code in sd. 3) Without more information I do not see the benefit. Is the gdipluscanvas faster or does it look better (e.g. antialiasing) then whatever the VCLCanvas uses.
@af: yes, gdipluscanvas does antialiasing. DirectX is platform-dependent as well. You don't need to change anything in your code. The only question is: did you really want _DirectX_ on more than one window, or was it rather antialiasing (from my recollection, the latter - DirectX will always come with double-buffering)? If the latter, please verify this issue. If the former, we need to move this issue to 3.1 at least.
How can I verify this issue without changing the code that creates the canvas for the presenter console extension? Does the canvas, that is created for the com.sun.star.rendering.VCLCanvas service, internally map to gdipluscanvas? The main problem described by this issue is (was, before the workaround of explicitly instancing VCLCanvas service) that there can only be one instance of the DirectX canvas. When the default service is used to create a canvas for the presenter console then this canvas can be the one DirectX canvas. This means that the canvas of the actual presentation is either a) a second DirectX canvas that conflicts with the first or b) another type of canvas that is not antialiased nor optimized with respect to rendering speed. Having a second antialiased and optimized canvas for the presenter console would be very nice but is of secondary importance. So, what I am looking for here is a canvas service that A) takes care of the DirectX problem (not stealing the single DirectX resource from the fullscreen presentation), B) is platform independent, and C) automatically provides the best (with respect to display quality and speed) canvas that is available on the platform.
@af: what I glean from your comments is that this issue is not fixed for you - spun off issue 90307 therefore, removing this from canvas05 & retargetting to 3.1. If you're interested, have a look into canvas/workben/canvasdemo.cxx (canvas05) about how to use the non-doublebuffering canvases.
This is effectively (though not literally) fixed in 3.1 now - simply use cairocanvas (if that's not enabled, please ask releng to build with ENABLE_CAIRO=TRUE). I'm afraid that sharing the DX device across more than one window is a bit involved & time is (again) running out... :(
@af: It's rather unlikely that I'll find time implementing that for windows. using the cairocanvas, also on windows, is I think a reasonable workaround. It would just need to be enabled for the Sun build.
Reset assigne to the default "issues@openoffice.apache.org".