Hello,
I am testing some OpenGL software that uses a DIB backed device
context followed by a BitBlt operation to draw graphics on to an
on-screen canvas.
Unfortunately this does not seem to work. I have tried to patch the
latest wine with DIB engine patches (bug 421), but, was unable to get
it working still.
My question(s) are:
1) Is this a known issue?
2) Is it in the scope of the DIB engine to fix this?
and this is slightly OT, but
3) Are there any alternatives for drawing OpenGL in to a invisible
buffer in a cross-platform transparent way?
I found the some simple example code here, that is quite small and
able to replicate the problem:
http://stackoverflow.com/questions/4052 ... background
I would really appreciate any input as I am a bit stuck at the moment.
-ravi
--
C-x C-s, C-x C-c
OpenGL + DIB
-
Thunderbird
- Level 5
- Posts: 336
- Joined: Mon Nov 24, 2008 8:10 am
OpenGL in combination with dibsection may be broken. I never really looked at this combination in the last couple of years since it is not that commonly used. The reason is that when you render to a bitmap (provided that's really what the application is doing) then you don't get any hardware acceleration at all on Windows. You are limited to pure OpenGL 1.1 software rendering.
The DIB engine won't fix the issue. In short Windows has a software and a hardware OpenGL implementation (the later is provided by your display driver). On Wine we only have the hardware one, so if the application requests software we still use the hardware one and nicely render to an X pixmap (we use indirect rendering in this particular case). Perhaps some of the sync code is broken and if it is, it could in theory be fixed.
There are several ways to render to a 'canvas':
- provided the canvas is a win32 child window, nothing prevents you from binding OpenGL to that window
- use OpenGL framebuffer objects (FBOs) as offscreen framebuffers; requires drivers which support this and to get the data out you would need to use glReadPixels
- use WGL pbuffers instead of a bitmap and again use glReadPixels
The DIB engine won't fix the issue. In short Windows has a software and a hardware OpenGL implementation (the later is provided by your display driver). On Wine we only have the hardware one, so if the application requests software we still use the hardware one and nicely render to an X pixmap (we use indirect rendering in this particular case). Perhaps some of the sync code is broken and if it is, it could in theory be fixed.
There are several ways to render to a 'canvas':
- provided the canvas is a win32 child window, nothing prevents you from binding OpenGL to that window
- use OpenGL framebuffer objects (FBOs) as offscreen framebuffers; requires drivers which support this and to get the data out you would need to use glReadPixels
- use WGL pbuffers instead of a bitmap and again use glReadPixels
