Layered windows and opengl

Hello,

Well I am a little bit disapointed using opengl and transparent windows on windows 2000 :

the transparent window flicks on top my opengl app and it’s really horrible !

So I searched on this forum and internet and it seems that there is no solution to solve this problem. I tryed several methods to draw my transparent window, so when the transparent window does not flicks there is a gray rectangle on the opengl app when I move the transparent window ;(

So my questions are :

  • is there really no way to do a clean job ?
  • why the mouse cursor does not flicks on top the opengl app ? (it’s not a transparent window too ?)

thx

why the mouse cursor does not flicks on top the opengl app ? (it’s not a transparent window too ?)
Because the mouse cursor is a cursor, not a window :wink:

The specification states that any part of an OpenGL window that is covered by another window has undefined contents. So there’s no real way to get around this.

Here is my solution to the problem.

…But before that… I am by no means more
than a complete newbie in windows programming,
so don’t even think about flaming me for the
way I do things. If there are alternatives…share with us.

Instead of using OpenGL to update the window contents
you could use it to render to the back buffer or
a pbuffer and then blit the results to the window.

Here is the code:

//it assumes the image was previously rendered
// hWnd is the handle to the window
// hDC is the handle to the device context of the window

  RECT rect;

        //find out the exact size of the bitmap we need
	GetClientRect(hWnd, &rect);

	winx = rect.right - rect.left ;
	winy = rect.bottom - rect.top ;

       //allocate memory to hold the bitmap data
	unsigned char* memory = (unsigned char*)malloc(winx * winy * 3);

        //read buffer into memory
	glReadPixels(0, 0, winx, winy, GL_RGB, GL_UNSIGNED_BYTE, memory);


     //setup the bitmap info (size, bitplanes...)
	BITMAPINFO bmi;

	memset(&bmi, 0, sizeof(bmi));
    bmi.bmiHeader.biSize        = sizeof(BITMAPINFOHEADER);
    bmi.bmiHeader.biWidth       = winx;
    bmi.bmiHeader.biHeight      = winy; // top-down image
    bmi.bmiHeader.biPlanes      = 1;
    bmi.bmiHeader.biBitCount    = 24;
	bmi.bmiHeader.biCompression = BI_RGB;
    bmi.bmiHeader.biSizeImage   = 0;


    //replace the current bitmap with the image from the framebuffer
	SetDIBitsToDevice(hDC, 0, 0, winx, winy, 0, 0, 0, winy, memory, &bmi, DIB_RGB_COLORS);

	free(memory);

I have not tested it thoroughly, so there may be some problems, but it works with no flickering
on my system.

It is slow though…

I hope it helps.

Originally posted by fuxiulian:
[b]Here is my solution to the problem.

…But before that… I am by no means more
than a complete newbie in windows programming,
so don’t even think about flaming me for the
way I do things. If there are alternatives…share with us.

Instead of using OpenGL to update the window contents
you could use it to render to the back buffer or
a pbuffer and then blit the results to the window.

Here is the code:

//it assumes the image was previously rendered
// hWnd is the handle to the window
// hDC is the handle to the device context of the window

  RECT rect;
    //find out the exact size of the bitmap we need

GetClientRect(hWnd, &rect);

winx = rect.right - rect.left ;
winy = rect.bottom - rect.top ;

   //allocate memory to hold the bitmap data

unsigned char* memory = (unsigned char*)malloc(winx * winy * 3);

    //read buffer into memory

glReadPixels(0, 0, winx, winy, GL_RGB, GL_UNSIGNED_BYTE, memory);

 //setup the bitmap info (size, bitplanes...)

BITMAPINFO bmi;

memset(&bmi, 0, sizeof(bmi));
bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
bmi.bmiHeader.biWidth = winx;
bmi.bmiHeader.biHeight = winy; // top-down image
bmi.bmiHeader.biPlanes = 1;
bmi.bmiHeader.biBitCount = 24;
bmi.bmiHeader.biCompression = BI_RGB;
bmi.bmiHeader.biSizeImage = 0;

//replace the current bitmap with the image from the framebuffer

SetDIBitsToDevice(hDC, 0, 0, winx, winy, 0, 0, 0, winy, memory, &bmi, DIB_RGB_COLORS);

free(memory);

I have not tested it thoroughly, so there may be some problems, but it works with no flickering 
on my system. 

It is slow though…

I hope it helps.[/b]


Well thx for your help, I’ll try your solution in the next days

So I found some demo in opengl having no problem with transparent windows !
What do they do ? …

Originally posted by Korval:
[b] [quote]why the mouse cursor does not flicks on top the opengl app ? (it’s not a transparent window too ?)
Because the mouse cursor is a cursor, not a window :wink:

The specification states that any part of an OpenGL window that is covered by another window has undefined contents. So there’s no real way to get around this.[/b][/QUOTE]_________________________________________

is there a way to have several mouse cursors on the screen (so we’ll have several transparent windows…)

So it seems that some video applications can write directly in the “primary surface”
(as windows media player)

Is it possible in opengl ?

Originally posted by Korval:
[b] [quote]why the mouse cursor does not flicks on top the opengl app ? (it’s not a transparent window too ?)
Because the mouse cursor is a cursor, not a window :wink:

The specification states that any part of an OpenGL window that is covered by another window has undefined contents. So there’s no real way to get around this.[/b][/QUOTE]After some research, I found that the mouse cursor is accelerated in hardware
That means that the graphic card have a specific buffer to draw the mouse cursor (3232 or 6464 or sometimes 128128 in true color)
Well after some tests small cursor (64
64) do not flick , it’s good but why is this buffer so small ? (It could be used to draw one transparent window !)

What has this got to do with opengl? This is an MS Windows question. Moderators are a fickle bunch - this half arsed topic continues unimpeded, as soda talks to himself about cursors and other basic win32 topics, while other more worthy topics get closed after the first post…I suppose it’s down to whether you use the term opengl enough, which soda obviously has, even though it’s a completely irrelevant term in this context.

duh? There is no moderator in this window-specific forum.

Originally posted by knackered:
What has this got to do with opengl? This is an MS Windows question. Moderators are a fickle bunch - this half arsed topic continues unimpeded, as soda talks to himself about cursors and other basic win32 topics, while other more worthy topics get closed after the first post…I suppose it’s down to whether you use the term opengl enough, which soda obviously has, even though it’s a completely irrelevant term in this context.
OLA, keep cool :wink:


I disagree with you : this is an opengl subject too because there is perhaps a way to solve this problem using opengl code.
Sorry to not be an opengl guru !

Okay I don’t put the topic in the good forum, sorry.

And I don’t talk to myself, I post what I found on this subject, if you are not interested do not read this post !!!

If you search on the old posts you’ll see that other people are intersted to do the same thing as me

bye :wink:

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.