Issue 81092 - DirectX support for canvas not available in all windows
Summary: DirectX support for canvas not available in all windows
Alias: None
Product: Draw
Classification: Application
Component: viewing (show other issues)
Version: 680m225
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2007-08-28 14:52 UTC by groucho266
Modified: 2017-05-20 10:48 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description groucho266 2007-08-28 14:52:10 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.
Comment 1 thb 2007-12-20 22:32:15 UTC
Mostly done.
Comment 2 thb 2008-01-15 08:57:37 UTC
Retargetted surrounding CWS.
Comment 3 groucho266 2008-03-04 17:57:22 UTC
Moved to successor CWS presenterscreen.
Comment 4 thb 2008-05-30 13:45:22 UTC
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).
Comment 5 thb 2008-06-02 22:17:57 UTC
@af: please verify in CWS canvas05, if this is acceptable - if not, we've got to
move this issue to 3.1
Comment 6 groucho266 2008-06-03 09:50:22 UTC
At the moment I am using a 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.
Comment 7 thb 2008-06-03 13:01:30 UTC
@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.
Comment 8 groucho266 2008-06-03 15:08:15 UTC
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 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.

Comment 9 thb 2008-06-03 16:02:18 UTC
@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.
Comment 10 thb 2009-01-07 16:28:51 UTC
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... :(
Comment 11 thb 2009-09-30 11:00:15 UTC
@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.
Comment 12 Marcus 2017-05-20 10:48:17 UTC
Reset assigne to the default "".