Hi guys, I'm writing a windowed inteface for plug-in software that has to
run in many different hosts. These hosts are third party, but provide a
window to use with the plug-ins.
Everything's fine apart from the odd report of massive slowdowns from users
in certain hosts, one in particular takes 1/4 second to render a thousand
polygons in my plug-in!
More info:

If I simply turn off double-bufferning I can see the traingles in cubes
rendering one at a time - it's so slow.

I'm restricting to OpenGL 1.1 for compatability.

I have the latest drivers for my NVidia 7600 GS.

Running on windows XP.

The host software is static, and I can minimize it with no speed up effect.

I've gone down to just rendering a cube, with one texture and I still have
rediculous slow rendering.

I've turned off anti-aliasing, and as much else I can think of, but with no
change.

I've tried rendering in a thread that is called only every 1/2 second, but
it just 'chuggs' when ever it is called again.

Any ideas?  - Just a quick hint would be fantastic from someone who's seen
this before.

Regards,
Jon.

> Hi guys, I'm writing a windowed inteface for plug-in software that has to
> run in many different hosts. These hosts are third party, but provide a
> window to use with the plug-ins.
> Everything's fine apart from the odd report of massive slowdowns from 
> users
> in certain hosts, one in particular takes 1/4 second to render a thousand
> polygons in my plug-in!
> More info:
>
> If I simply turn off double-bufferning I can see the traingles in cubes
> rendering one at a time - it's so slow.
>
> I'm restricting to OpenGL 1.1 for compatability.
>
> I have the latest drivers for my NVidia 7600 GS.
>
> Running on windows XP.
>
> The host software is static, and I can minimize it with no speed up 
> effect.
>
> I've gone down to just rendering a cube, with one texture and I still have
> rediculous slow rendering.
>
> I've turned off anti-aliasing, and as much else I can think of, but with 
> no
> change.
>
> I've tried rendering in a thread that is called only every 1/2 second, but
> it just 'chuggs' when ever it is called again.
>
> Any ideas?  - Just a quick hint would be fantastic from someone who's seen
> this before.
>
> Regards,
> Jon.

O.K. I've got a little more information, if I make a window that is NOT a 
'WS_CHILD' then everything runs perfectly - really fast indeed.
But as soon as it's a child window, then it breaks horribly.
I'm also getting a really short extension string like this:-
"GL_WIN_swap_hint GL_EXT_bgra GL_EXT_paletted_texture" and that's it!  - 
When the window is not a child I get the proper big list of 3000 characters 
or so.
I did not realise that applications can control the OpenGL extension 
parameters themselves!
Is this expected, and can I fix it? I don't want to create another separate 
window for it, as it will look very messy.

Thanks again.

"VelociChicken" <bob@yahoob.com> wrote in message 
news:L1oGl.62449$ga.7810@newsfe01.ams2...
>> Hi guys, I'm writing a windowed inteface for plug-in software that has to
>> run in many different hosts. These hosts are third party, but provide a
>> window to use with the plug-ins.
>> Everything's fine apart from the odd report of massive slowdowns from 
>> users
>> in certain hosts, one in particular takes 1/4 second to render a thousand
>> polygons in my plug-in!
>> More info:
>>
>> If I simply turn off double-bufferning I can see the traingles in cubes
>> rendering one at a time - it's so slow.
>>
>> I'm restricting to OpenGL 1.1 for compatability.
>>
>> I have the latest drivers for my NVidia 7600 GS.
>>
>> Running on windows XP.
>>
>> The host software is static, and I can minimize it with no speed up 
>> effect.
>>
>> I've gone down to just rendering a cube, with one texture and I still 
>> have
>> rediculous slow rendering.
>>
>> I've turned off anti-aliasing, and as much else I can think of, but with 
>> no
>> change.
>>
>> I've tried rendering in a thread that is called only every 1/2 second, 
>> but
>> it just 'chuggs' when ever it is called again.
>>
>> Any ideas?  - Just a quick hint would be fantastic from someone who's 
>> seen
>> this before.
>>
>> Regards,
>> Jon.
>
> O.K. I've got a little more information, if I make a window that is NOT a 
> 'WS_CHILD' then everything runs perfectly - really fast indeed.
> But as soon as it's a child window, then it breaks horribly.
> I'm also getting a really short extension string like this:-
> "GL_WIN_swap_hint GL_EXT_bgra GL_EXT_paletted_texture" and that's it!  - 
> When the window is not a child I get the proper big list of 3000 
> characters or so.
> I did not realise that applications can control the OpenGL extension 
> parameters themselves!
> Is this expected, and can I fix it? I don't want to create another 
> separate window for it, as it will look very messy.
>
> Thanks again.
>
>
>

You're choosing (or getting) the wrong pixelformat -- you are getting a 
pure-software emulation OpenGL from Microsoft. Has to do with being unable 
to change the pixelformat once set, presumably because you are a child. If 
your pixel format isn't accelerated, if forget now which flag to look for in 
the actual pixelformat you get, (opengl will report GDI Generic as the 
driver string), then I think you lose.

jbw 

"jbwest" <jbwest@acm.org> wrote in message 
news:49ea2c5b$0$29139$6e1ede2f@read.cnntp.org...
>
> "VelociChicken" <bob@yahoob.com> wrote in message 
> news:L1oGl.62449$ga.7810@newsfe01.ams2...
>>> Hi guys, I'm writing a windowed inteface for plug-in software that has 
>>> to
>>> run in many different hosts. These hosts are third party, but provide a
>>> window to use with the plug-ins.
>>> Everything's fine apart from the odd report of massive slowdowns from 
>>> users
>>> in certain hosts, one in particular takes 1/4 second to render a 
>>> thousand
>>> polygons in my plug-in!
>>> More info:
>>>
>>> If I simply turn off double-bufferning I can see the traingles in cubes
>>> rendering one at a time - it's so slow.
>>>
>>> I'm restricting to OpenGL 1.1 for compatability.
>>>
>>> I have the latest drivers for my NVidia 7600 GS.
>>>
>>> Running on windows XP.
>>>
>>> The host software is static, and I can minimize it with no speed up 
>>> effect.
>>>
>>> I've gone down to just rendering a cube, with one texture and I still 
>>> have
>>> rediculous slow rendering.
>>>
>>> I've turned off anti-aliasing, and as much else I can think of, but with 
>>> no
>>> change.
>>>
>>> I've tried rendering in a thread that is called only every 1/2 second, 
>>> but
>>> it just 'chuggs' when ever it is called again.
>>>
>>> Any ideas?  - Just a quick hint would be fantastic from someone who's 
>>> seen
>>> this before.
>>>
>>> Regards,
>>> Jon.
>>
>> O.K. I've got a little more information, if I make a window that is NOT a 
>> 'WS_CHILD' then everything runs perfectly - really fast indeed.
>> But as soon as it's a child window, then it breaks horribly.
>> I'm also getting a really short extension string like this:-
>> "GL_WIN_swap_hint GL_EXT_bgra GL_EXT_paletted_texture" and that's it!  - 
>> When the window is not a child I get the proper big list of 3000 
>> characters or so.
>> I did not realise that applications can control the OpenGL extension 
>> parameters themselves!
>> Is this expected, and can I fix it? I don't want to create another 
>> separate window for it, as it will look very messy.
>>
>> Thanks again.
>>
>>
>>
>
> You're choosing (or getting) the wrong pixelformat -- you are getting a 
> pure-software emulation OpenGL from Microsoft. Has to do with being unable 
> to change the pixelformat once set, presumably because you are a child. If 
> your pixel format isn't accelerated, if forget now which flag to look for 
> in the actual pixelformat you get, (opengl will report GDI Generic as the 
> driver string), then I think you lose.
>
> jbw

Thanks fort reply jbw.
O.K. I'm getting Microsoft Corp. as the "glGetString(GL_VENDOR) " so I guess 
it must be software rendering.
 I've tried creating a seperate window instead (which gives "NVIDIA corp"), 
then post adding to the parent by doing something like this:-

SetWindowLong(tempHWnd, GWL_STYLE, WS_CHILD|WS_CLIPSIBLINGS | 
WS_CLIPCHILDREN |WS_VISIBLE);
SetWindowPos( tempHWnd, 0, 0, 0, 400,400, SWP_NOZORDER|SWP_FRAMECHANGED ); 
// 400 being the window size
SetParent(tempHWnd, parentHWnd);
ShowWindow(tempHWnd, SW_SHOW );
SetForegroundWindow( tempHWnd );

...But I'm getting either a black square or it goes back to being slow when 
attached back the parent.

Am I completely stuffed by this? Is there no way to force the child to use 
proper acceleration?

Cheers,
J

"VelociChicken" <bob@yahoob.com> wrote in message 
news:sUqGl.88689$AS.17062@newsfe03.ams2...
>
> "jbwest" <jbwest@acm.org> wrote in message 
> news:49ea2c5b$0$29139$6e1ede2f@read.cnntp.org...
>>
>> "VelociChicken" <bob@yahoob.com> wrote in message 
>> news:L1oGl.62449$ga.7810@newsfe01.ams2...
>>>> Hi guys, I'm writing a windowed inteface for plug-in software that has 
>>>> to
>>>> run in many different hosts. These hosts are third party, but provide a
>>>> window to use with the plug-ins.
>>>> Everything's fine apart from the odd report of massive slowdowns from 
>>>> users
>>>> in certain hosts, one in particular takes 1/4 second to render a 
>>>> thousand
>>>> polygons in my plug-in!
>>>> More info:
>>>>
>>>> If I simply turn off double-bufferning I can see the traingles in cubes
>>>> rendering one at a time - it's so slow.
>>>>
>>>> I'm restricting to OpenGL 1.1 for compatability.
>>>>
>>>> I have the latest drivers for my NVidia 7600 GS.
>>>>
>>>> Running on windows XP.
>>>>
>>>> The host software is static, and I can minimize it with no speed up 
>>>> effect.
>>>>
>>>> I've gone down to just rendering a cube, with one texture and I still 
>>>> have
>>>> rediculous slow rendering.
>>>>
>>>> I've turned off anti-aliasing, and as much else I can think of, but 
>>>> with no
>>>> change.
>>>>
>>>> I've tried rendering in a thread that is called only every 1/2 second, 
>>>> but
>>>> it just 'chuggs' when ever it is called again.
>>>>
>>>> Any ideas?  - Just a quick hint would be fantastic from someone who's 
>>>> seen
>>>> this before.
>>>>
>>>> Regards,
>>>> Jon.
>>>
>>> O.K. I've got a little more information, if I make a window that is NOT 
>>> a 'WS_CHILD' then everything runs perfectly - really fast indeed.
>>> But as soon as it's a child window, then it breaks horribly.
>>> I'm also getting a really short extension string like this:-
>>> "GL_WIN_swap_hint GL_EXT_bgra GL_EXT_paletted_texture" and that's it!  - 
>>> When the window is not a child I get the proper big list of 3000 
>>> characters or so.
>>> I did not realise that applications can control the OpenGL extension 
>>> parameters themselves!
>>> Is this expected, and can I fix it? I don't want to create another 
>>> separate window for it, as it will look very messy.
>>>
>>> Thanks again.
>>>
>>>
>>>
>>
>> You're choosing (or getting) the wrong pixelformat -- you are getting a 
>> pure-software emulation OpenGL from Microsoft. Has to do with being 
>> unable to change the pixelformat once set, presumably because you are a 
>> child. If your pixel format isn't accelerated, if forget now which flag 
>> to look for in the actual pixelformat you get, (opengl will report GDI 
>> Generic as the driver string), then I think you lose.
>>
>> jbw
>
> Thanks fort reply jbw.
> O.K. I'm getting Microsoft Corp. as the "glGetString(GL_VENDOR) " so I 
> guess it must be software rendering.
> I've tried creating a seperate window instead (which gives "NVIDIA corp"), 
> then post adding to the parent by doing something like this:-
>
> SetWindowLong(tempHWnd, GWL_STYLE, WS_CHILD|WS_CLIPSIBLINGS | 
> WS_CLIPCHILDREN |WS_VISIBLE);
> SetWindowPos( tempHWnd, 0, 0, 0, 400,400, SWP_NOZORDER|SWP_FRAMECHANGED ); 
> // 400 being the window size
> SetParent(tempHWnd, parentHWnd);
> ShowWindow(tempHWnd, SW_SHOW );
> SetForegroundWindow( tempHWnd );
>
> ..But I'm getting either a black square or it goes back to being slow when 
> attached back the parent.
>
> Am I completely stuffed by this? Is there no way to force the child to use 
> proper acceleration?
>
> Cheers,
> J
>
>
>
>
>
>
>

You need to look up the limitations of "changepixelformat". I think it can 
be done once, so if the parent hasn't been changed before, you can change 
it. This is an MS pixelformat issue, not specifically opengl. Maybe a more 
M$ oriented newsgroup would be better.

jbw

>
> 

VelociChicken wrote:

> 
> "jbwest" <jbwest@acm.org> wrote in message
> news:49ea2c5b$0$29139$6e1ede2f@read.cnntp.org...
>>
>> "VelociChicken" <bob@yahoob.com> wrote in message
>> news:L1oGl.62449$ga.7810@newsfe01.ams2...
>> You're choosing (or getting) the wrong pixelformat -- you are getting a
>> pure-software emulation OpenGL from Microsoft. Has to do with being
>> unable to change the pixelformat once set, presumably because you are a
>> child. If your pixel format isn't accelerated, if forget now which flag
>> to look for in the actual pixelformat you get, (opengl will report GDI
>> Generic as the driver string), then I think you lose.
>>
>> jbw
> 
> Thanks fort reply jbw.
> O.K. I'm getting Microsoft Corp. as the "glGetString(GL_VENDOR) " so I
> guess it must be software rendering.
>  I've tried creating a seperate window instead (which gives "NVIDIA
>  corp"),
> then post adding to the parent by doing something like this:-
> 
> SetWindowLong(tempHWnd, GWL_STYLE, WS_CHILD|WS_CLIPSIBLINGS |
> WS_CLIPCHILDREN |WS_VISIBLE);
> SetWindowPos( tempHWnd, 0, 0, 0, 400,400, SWP_NOZORDER|SWP_FRAMECHANGED );
> // 400 being the window size
> SetParent(tempHWnd, parentHWnd);
> ShowWindow(tempHWnd, SW_SHOW );
> SetForegroundWindow( tempHWnd );
> 
> ..But I'm getting either a black square or it goes back to being slow when
> attached back the parent.
> 
> Am I completely stuffed by this? Is there no way to force the child to use
> proper acceleration?
> 
> Cheers,
> J

This may be an implementation detail that is difficult to work around.  The
way windows are composited/blended/copied starting with the base window
layer, and then the children (in stacking order), it may be that enabling a
child to have OpenGL hardware acceleration is not possible with the
existing constraints of Microsoft Windows.  They most likely use software
rasterization for some of the process without OpenGL.  There is certainly
nothing to stop you from implementing your own window system with OpenGL
though too.  More than a few people have made OpenGL toolkits that
implement window layers.  You could use textures to store some window
contents, although that's not the only way.  The problem could also have
something to do with an nvidia driver limitation as well.  I would ask
nvidia what they support.

-George

"George Peter Staplin" <georgeps@xmission.com> wrote in message 
news:gsdpfr$j42$1@news.xmission.com...
> VelociChicken wrote:
>
>>
>> "jbwest" <jbwest@acm.org> wrote in message
>> news:49ea2c5b$0$29139$6e1ede2f@read.cnntp.org...
>>>
>>> "VelociChicken" <bob@yahoob.com> wrote in message
>>> news:L1oGl.62449$ga.7810@newsfe01.ams2...
>>> You're choosing (or getting) the wrong pixelformat -- you are getting a
>>> pure-software emulation OpenGL from Microsoft. Has to do with being
>>> unable to change the pixelformat once set, presumably because you are a
>>> child. If your pixel format isn't accelerated, if forget now which flag
>>> to look for in the actual pixelformat you get, (opengl will report GDI
>>> Generic as the driver string), then I think you lose.
>>>
>>> jbw
>>
>> Thanks fort reply jbw.
>> O.K. I'm getting Microsoft Corp. as the "glGetString(GL_VENDOR) " so I
>> guess it must be software rendering.
>>  I've tried creating a seperate window instead (which gives "NVIDIA
>>  corp"),
>> then post adding to the parent by doing something like this:-
>>
>> SetWindowLong(tempHWnd, GWL_STYLE, WS_CHILD|WS_CLIPSIBLINGS |
>> WS_CLIPCHILDREN |WS_VISIBLE);
>> SetWindowPos( tempHWnd, 0, 0, 0, 400,400, 
>> SWP_NOZORDER|SWP_FRAMECHANGED );
>> // 400 being the window size
>> SetParent(tempHWnd, parentHWnd);
>> ShowWindow(tempHWnd, SW_SHOW );
>> SetForegroundWindow( tempHWnd );
>>
>> ..But I'm getting either a black square or it goes back to being slow 
>> when
>> attached back the parent.
>>
>> Am I completely stuffed by this? Is there no way to force the child to 
>> use
>> proper acceleration?
>>
>> Cheers,
>> J
>
> This may be an implementation detail that is difficult to work around. 
> The
> way windows are composited/blended/copied starting with the base window
> layer, and then the children (in stacking order), it may be that enabling 
> a
> child to have OpenGL hardware acceleration is not possible with the
> existing constraints of Microsoft Windows.  They most likely use software
> rasterization for some of the process without OpenGL.  There is certainly
> nothing to stop you from implementing your own window system with OpenGL
> though too.  More than a few people have made OpenGL toolkits that
> implement window layers.  You could use textures to store some window
> contents, although that's not the only way.  The problem could also have
> something to do with an nvidia driver limitation as well.  I would ask
> nvidia what they support.
>
> -George

Thanks George, that's given me some hope.
I can have a separate window, which works fine, but then the user has two 
windows for one plug-in, which isn't what they're used to, and a bit messy 
too.
Can I make the off-screen content in hardware, and let the host simply draw 
the one texture to a quad in the window to speed it up - is that what you're 
saying?
I get the feeling I need to learn a lot more now, can you give any hints on 
where to look for these ideas and toolkits?

Thanks
Jon

"VelociChicken" <bob@yahoob.com> wrote in message 
news:QXFGl.88705$AS.50920@newsfe03.ams2...
>
> "George Peter Staplin" <georgeps@xmission.com> wrote in message 
> news:gsdpfr$j42$1@news.xmission.com...
>> VelociChicken wrote:
>>
>>>
>>> "jbwest" <jbwest@acm.org> wrote in message
>>> news:49ea2c5b$0$29139$6e1ede2f@read.cnntp.org...
>>>>
>>>> "VelociChicken" <bob@yahoob.com> wrote in message
>>>> news:L1oGl.62449$ga.7810@newsfe01.ams2...
>>>> You're choosing (or getting) the wrong pixelformat -- you are getting a
>>>> pure-software emulation OpenGL from Microsoft. Has to do with being
>>>> unable to change the pixelformat once set, presumably because you are a
>>>> child. If your pixel format isn't accelerated, if forget now which flag
>>>> to look for in the actual pixelformat you get, (opengl will report GDI
>>>> Generic as the driver string), then I think you lose.
>>>>
>>>> jbw
>>>
>>> Thanks fort reply jbw.
>>> O.K. I'm getting Microsoft Corp. as the "glGetString(GL_VENDOR) " so I
>>> guess it must be software rendering.
>>>  I've tried creating a seperate window instead (which gives "NVIDIA
>>>  corp"),
>>> then post adding to the parent by doing something like this:-
>>>
>>> SetWindowLong(tempHWnd, GWL_STYLE, WS_CHILD|WS_CLIPSIBLINGS |
>>> WS_CLIPCHILDREN |WS_VISIBLE);
>>> SetWindowPos( tempHWnd, 0, 0, 0, 400,400, 
>>> SWP_NOZORDER|SWP_FRAMECHANGED );
>>> // 400 being the window size
>>> SetParent(tempHWnd, parentHWnd);
>>> ShowWindow(tempHWnd, SW_SHOW );
>>> SetForegroundWindow( tempHWnd );
>>>
>>> ..But I'm getting either a black square or it goes back to being slow 
>>> when
>>> attached back the parent.
>>>
>>> Am I completely stuffed by this? Is there no way to force the child to 
>>> use
>>> proper acceleration?
>>>
>>> Cheers,
>>> J
>>
>> This may be an implementation detail that is difficult to work around. 
>> The
>> way windows are composited/blended/copied starting with the base window
>> layer, and then the children (in stacking order), it may be that enabling 
>> a
>> child to have OpenGL hardware acceleration is not possible with the
>> existing constraints of Microsoft Windows.  They most likely use software
>> rasterization for some of the process without OpenGL.  There is certainly
>> nothing to stop you from implementing your own window system with OpenGL
>> though too.  More than a few people have made OpenGL toolkits that
>> implement window layers.  You could use textures to store some window
>> contents, although that's not the only way.  The problem could also have
>> something to do with an nvidia driver limitation as well.  I would ask
>> nvidia what they support.
>>
>> -George
>
> Thanks George, that's given me some hope.
> I can have a separate window, which works fine, but then the user has two 
> windows for one plug-in, which isn't what they're used to, and a bit messy 
> too.
> Can I make the off-screen content in hardware, and let the host simply 
> draw the one texture to a quad in the window to speed it up - is that what 
> you're saying?
> I get the feeling I need to learn a lot more now, can you give any hints 
> on where to look for these ideas and toolkits?
>
> Thanks
> Jon
>
>
>
>
>
>

Yes, you can always (almost) get a p-buffer offscreen accelerated rendering 
context and pay the price of a bit-blt to a plain gdi child window. It's 
certainly much faster than the current path you are on.

it is NOT a driver limitation as suggested by previous post, it purely has 
to do with the pixelformat of the child window.
Check the return code and values from you setpixelformat/querypixleformat 
and you'll see that setpixelformat is NOT giving you a pixel format suitable 
for opengl acceleration.

jbw
>
>
> 

"jbwest" <jbwest@acm.org> wrote in message 
news:49eb3ad7$0$29139$6e1ede2f@read.cnntp.org...
>
> "VelociChicken" <bob@yahoob.com> wrote in message 
> news:QXFGl.88705$AS.50920@newsfe03.ams2...
>>
>> "George Peter Staplin" <georgeps@xmission.com> wrote in message 
>> news:gsdpfr$j42$1@news.xmission.com...
>>> VelociChicken wrote:
>>>
>>>>
>>>> "jbwest" <jbwest@acm.org> wrote in message
>>>> news:49ea2c5b$0$29139$6e1ede2f@read.cnntp.org...
>>>>>
>>>>> "VelociChicken" <bob@yahoob.com> wrote in message
>>>>> news:L1oGl.62449$ga.7810@newsfe01.ams2...
>>>>> You're choosing (or getting) the wrong pixelformat -- you are getting 
>>>>> a
>>>>> pure-software emulation OpenGL from Microsoft. Has to do with being
>>>>> unable to change the pixelformat once set, presumably because you are 
>>>>> a
>>>>> child. If your pixel format isn't accelerated, if forget now which 
>>>>> flag
>>>>> to look for in the actual pixelformat you get, (opengl will report GDI
>>>>> Generic as the driver string), then I think you lose.
>>>>>
>>>>> jbw
>>>>
>>>> Thanks fort reply jbw.
>>>> O.K. I'm getting Microsoft Corp. as the "glGetString(GL_VENDOR) " so I
>>>> guess it must be software rendering.
>>>>  I've tried creating a seperate window instead (which gives "NVIDIA
>>>>  corp"),
>>>> then post adding to the parent by doing something like this:-
>>>>
>>>> SetWindowLong(tempHWnd, GWL_STYLE, WS_CHILD|WS_CLIPSIBLINGS |
>>>> WS_CLIPCHILDREN |WS_VISIBLE);
>>>> SetWindowPos( tempHWnd, 0, 0, 0, 400,400, 
>>>> SWP_NOZORDER|SWP_FRAMECHANGED );
>>>> // 400 being the window size
>>>> SetParent(tempHWnd, parentHWnd);
>>>> ShowWindow(tempHWnd, SW_SHOW );
>>>> SetForegroundWindow( tempHWnd );
>>>>
>>>> ..But I'm getting either a black square or it goes back to being slow 
>>>> when
>>>> attached back the parent.
>>>>
>>>> Am I completely stuffed by this? Is there no way to force the child to 
>>>> use
>>>> proper acceleration?
>>>>
>>>> Cheers,
>>>> J
>>>
>>> This may be an implementation detail that is difficult to work around. 
>>> The
>>> way windows are composited/blended/copied starting with the base window
>>> layer, and then the children (in stacking order), it may be that 
>>> enabling a
>>> child to have OpenGL hardware acceleration is not possible with the
>>> existing constraints of Microsoft Windows.  They most likely use 
>>> software
>>> rasterization for some of the process without OpenGL.  There is 
>>> certainly
>>> nothing to stop you from implementing your own window system with OpenGL
>>> though too.  More than a few people have made OpenGL toolkits that
>>> implement window layers.  You could use textures to store some window
>>> contents, although that's not the only way.  The problem could also have
>>> something to do with an nvidia driver limitation as well.  I would ask
>>> nvidia what they support.
>>>
>>> -George
>>
>> Thanks George, that's given me some hope.
>> I can have a separate window, which works fine, but then the user has two 
>> windows for one plug-in, which isn't what they're used to, and a bit 
>> messy too.
>> Can I make the off-screen content in hardware, and let the host simply 
>> draw the one texture to a quad in the window to speed it up - is that 
>> what you're saying?
>> I get the feeling I need to learn a lot more now, can you give any hints 
>> on where to look for these ideas and toolkits?
>>
>> Thanks
>> Jon
>>
>>
>
> Yes, you can always (almost) get a p-buffer offscreen accelerated 
> rendering context and pay the price of a bit-blt to a plain gdi child 
> window. It's certainly much faster than the current path you are on.
>
> it is NOT a driver limitation as suggested by previous post, it purely has 
> to do with the pixelformat of the child window.
> Check the return code and values from you setpixelformat/querypixleformat 
> and you'll see that setpixelformat is NOT giving you a pixel format 
> suitable for opengl acceleration.
> jbw

That sounds the definitive answer I was hoping for, the 'bit-blt' will be 
fast I'm sure.
 It sounds like there is NO WAY to force the child window to be accelerated, 
so it looks like I'll be off-screening it.
Cheers,
J

 Yes, you can always (almost) get a p-buffer offscreen accelerated rendering
> context and pay the price of a bit-blt to a plain gdi child window. It's 
> certainly much faster than the current path you are on.
> jbw

Thanks.
Can I just confirm something?

I have to create an invisible window with "CreateWindowEx" then create a 
pbuffer on that, checking the attibutes first.
Then create a visible window on the child being sent from host.
Do a wglMakeCurrent on the pbuffer.
Do all the rendering.

Make the the visible window current and draw a quad with the pbuffer texture
OR
Make a texture from the p-bitmap data, and use windows to draw it.

Is this O.K? I guess I really do have to make TWO windows yes?

"VelociChicken" <bob@yahoob.com> wrote in message 
news:1sLGl.38809$eO4.3330@newsfe09.ams2...
> Yes, you can always (almost) get a p-buffer offscreen accelerated 
> rendering
>> context and pay the price of a bit-blt to a plain gdi child window. It's 
>> certainly much faster than the current path you are on.
>> jbw
>
> Thanks.
> Can I just confirm something?
>
> I have to create an invisible window with "CreateWindowEx" then create a 
> pbuffer on that, checking the attibutes first.
> Then create a visible window on the child being sent from host.
> Do a wglMakeCurrent on the pbuffer.
> Do all the rendering.
>
> Make the the visible window current and draw a quad with the pbuffer 
> texture
> OR
> Make a texture from the p-bitmap data, and use windows to draw it.
>
> Is this O.K? I guess I really do have to make TWO windows yes?
>
>

That's about it, but rather than textures I'd just read the p-buffer 
contents with glreadPixels and convert it for a bit-blt using windows 
methods.

jbw

> "VelociChicken" <bob@yahoob.com> wrote in message 
> news:1sLGl.38809$eO4.3330@newsfe09.ams2...
>> Yes, you can always (almost) get a p-buffer offscreen accelerated 
>> rendering
>>> context and pay the price of a bit-blt to a plain gdi child window. It's 
>>> certainly much faster than the current path you are on.
>>> jbw
>>
>> Thanks.
>> Can I just confirm something?
>>
>> I have to create an invisible window with "CreateWindowEx" then create a 
>> pbuffer on that, checking the attibutes first.
>> Then create a visible window on the child being sent from host.
>> Do a wglMakeCurrent on the pbuffer.
>> Do all the rendering.
>>
>> Make the the visible window current and draw a quad with the pbuffer 
>> texture
>> OR
>> Make a texture from the p-bitmap data, and use windows to draw it.
>>
>> Is this O.K? I guess I really do have to make TWO windows yes?
>>
>
> That's about it, but rather than textures I'd just read the p-buffer 
> contents with glreadPixels and convert it for a bit-blt using windows 
> methods.
> jbw
>

Thanks jb, you've been very helpful. After some time looking into the 
extensions needed, I'm still a little confused...
If I create a new floating window anyway, can't a render to this and then 
copy the data over?
It just seems that making a new window, then adding a pbuffer to it seems a 
bit OTT. Can't I render straight to the invisible window the read the pixels 
from that?
Thanks again, hopefully it will all sink in soon, it's just that its 
starting to look over complex.

Cheers,
J

"VelociChicken" <bob@yahoob.com> wrote in message 
news:m8%Gl.44105$rk7.21779@newsfe05.ams2...
>> "VelociChicken" <bob@yahoob.com> wrote in message 
>> news:1sLGl.38809$eO4.3330@newsfe09.ams2...
>>> Yes, you can always (almost) get a p-buffer offscreen accelerated 
>>> rendering
>>>> context and pay the price of a bit-blt to a plain gdi child window. 
>>>> It's certainly much faster than the current path you are on.
>>>> jbw
>>>
>>> Thanks.
>>> Can I just confirm something?
>>>
>>> I have to create an invisible window with "CreateWindowEx" then create a 
>>> pbuffer on that, checking the attibutes first.
>>> Then create a visible window on the child being sent from host.
>>> Do a wglMakeCurrent on the pbuffer.
>>> Do all the rendering.
>>>
>>> Make the the visible window current and draw a quad with the pbuffer 
>>> texture
>>> OR
>>> Make a texture from the p-bitmap data, and use windows to draw it.
>>>
>>> Is this O.K? I guess I really do have to make TWO windows yes?
>>>
>>
>> That's about it, but rather than textures I'd just read the p-buffer 
>> contents with glreadPixels and convert it for a bit-blt using windows 
>> methods.
>> jbw
>>
>
> Thanks jb, you've been very helpful. After some time looking into the 
> extensions needed, I'm still a little confused...
> If I create a new floating window anyway, can't a render to this and then 
> copy the data over?
> It just seems that making a new window, then adding a pbuffer to it seems 
> a bit OTT. Can't I render straight to the invisible window the read the 
> pixels from that?
> Thanks again, hopefully it will all sink in soon, it's just that its 
> starting to look over complex.
>
> Cheers,
> J
>
>

No, you cannot render to an obscured or invisible window and expect to read 
back anything useful.
Windows have valid framebuffer contents *only*in the *visible* portions of 
them. That's why you need an offscreen
p-buffer, it *can* be rendered on and read back without any pixels being 
visible. A more modern concept, a FrameBufferObject, is a cleaner 
implementation of the idea but may not be quite as universally supported.

Having to have an invisible window is a microsoft artifact only, and not 
really part of what OpenGL is about (pixelformats & such). One doesn't need 
"dummy" windows on Linux.

2 notes;
   pbuffers are probably usually single-buffered framebuffers
   you need to destroy & recreate it if the target window size changes, (I 
don't think pbuffers can be resized, but don't totally remember).

jbw

"jbwest" <jbwest@acm.org> wrote in message 
news:49ecc4ea$0$29138$6e1ede2f@read.cnntp.org...
>
> "VelociChicken" <bob@yahoob.com> wrote in message 
> news:m8%Gl.44105$rk7.21779@newsfe05.ams2...
>> It just seems that making a new window, then adding a pbuffer to it seems 
>> a bit OTT. Can't I render straight to the invisible window the read the 
>> pixels from that?
>> Thanks again, hopefully it will all sink in soon, it's just that its 
>> starting to look over complex.
>>
>> Cheers,
>> J
>>
>>
>
> No, you cannot render to an obscured or invisible window and expect to 
> read back anything useful.
> Windows have valid framebuffer contents *only*in the *visible* portions of 
> them. That's why you need an offscreen
> p-buffer, it *can* be rendered on and read back without any pixels being 
> visible. A more modern concept, a FrameBufferObject, is a cleaner 
> implementation of the idea but may not be quite as universally supported.
>
> Having to have an invisible window is a microsoft artifact only, and not 
> really part of what OpenGL is about (pixelformats & such). One doesn't 
> need "dummy" windows on Linux.

With NVIDIA 7x and 8x cards you may create window DC using NVIDIA
extension wglCreateAffinityDCNV. Initially you still need invisible window
to initialize OpenGL and query supported extensions but once it's done this
window could be disposed.

Just keep in mind that this is affinity DC meaning that GL objects created
on one GPU couldn't be shared/used on the other GPU.

> 2 notes;
>   pbuffers are probably usually single-buffered framebuffers
>   you need to destroy & recreate it if the target window size changes, (I 
> don't think pbuffers can be resized, but don't totally remember).

Most likely you are right :-(
So you have two choices - recreate p-buffer/FBO each time or create it
just once "big enough" (e.g. 2560x2048) and this becomes memory/speed
tradeof.

Create FBO could be costly and for some applications even time-critical
operation. In their latest drivers NVIDIA tweaked up the performance but
still it's about 80-90 mSec.

> jbw
>

Georgy 

"Georgy Malyshev" <x@y.z> wrote in message 
news:49eda831$0$22528$607ed4bc@cv.net...
>
> "jbwest" <jbwest@acm.org> wrote in message 
> news:49ecc4ea$0$29138$6e1ede2f@read.cnntp.org...
>>
>> "VelociChicken" <bob@yahoob.com> wrote in message 
>> news:m8%Gl.44105$rk7.21779@newsfe05.ams2...
>>> It just seems that making a new window, then adding a pbuffer to it 
>>> seems a bit OTT. Can't I render straight to the invisible window the 
>>> read the pixels from that?
>>> Thanks again, hopefully it will all sink in soon, it's just that its 
>>> starting to look over complex.
>>>
>>> Cheers,
>>> J
>>>
>>>
>>
>> No, you cannot render to an obscured or invisible window and expect to 
>> read back anything useful.
>> Windows have valid framebuffer contents *only*in the *visible* portions 
>> of them. That's why you need an offscreen
>> p-buffer, it *can* be rendered on and read back without any pixels being 
>> visible. A more modern concept, a FrameBufferObject, is a cleaner 
>> implementation of the idea but may not be quite as universally supported.
>>
>> Having to have an invisible window is a microsoft artifact only, and not 
>> really part of what OpenGL is about (pixelformats & such). One doesn't 
>> need "dummy" windows on Linux.
>
> With NVIDIA 7x and 8x cards you may create window DC using NVIDIA
> extension wglCreateAffinityDCNV. Initially you still need invisible window
> to initialize OpenGL and query supported extensions but once it's done 
> this
> window could be disposed.
>
> Just keep in mind that this is affinity DC meaning that GL objects created
> on one GPU couldn't be shared/used on the other GPU.
>
>> 2 notes;
>>   pbuffers are probably usually single-buffered framebuffers
>>   you need to destroy & recreate it if the target window size changes, (I 
>> don't think pbuffers can be resized, but don't totally remember).
>
> Most likely you are right :-(
> So you have two choices - recreate p-buffer/FBO each time or create it
> just once "big enough" (e.g. 2560x2048) and this becomes memory/speed
> tradeof.
>
> Create FBO could be costly and for some applications even time-critical
> operation. In their latest drivers NVIDIA tweaked up the performance but
> still it's about 80-90 mSec.
>
>> jbw
>>
>
> Georgy

O.K. thanks guys. I need compatibitily going a while back, so I'll stick 
with the pbuffer.
The code creates a window, checks the extensions, deletes window and creates 
a new one with extensions, then creates pbuffer - such a large amount of 
code!

"VelociChicken" <bob@yahoob.com> wrote in message 
news:pmkHl.31385$KB5.26489@newsfe11.ams2...
>
> "Georgy Malyshev" <x@y.z> wrote in message 
> news:49eda831$0$22528$607ed4bc@cv.net...
>>
>> "jbwest" <jbwest@acm.org> wrote in message 
>> news:49ecc4ea$0$29138$6e1ede2f@read.cnntp.org...
>>>
>>> "VelociChicken" <bob@yahoob.com> wrote in message 
>>> news:m8%Gl.44105$rk7.21779@newsfe05.ams2...
>>>> It just seems that making a new window, then adding a pbuffer to it 
>>>> seems a bit OTT. Can't I render straight to the invisible window the 
>>>> read the pixels from that?
>>>> Thanks again, hopefully it will all sink in soon, it's just that its 
>>>> starting to look over complex.
>>>>
>>>> Cheers,
>>>> J
>>>>
>>>>
>>>
>>> No, you cannot render to an obscured or invisible window and expect to 
>>> read back anything useful.
>>> Windows have valid framebuffer contents *only*in the *visible* portions 
>>> of them. That's why you need an offscreen
>>> p-buffer, it *can* be rendered on and read back without any pixels being 
>>> visible. A more modern concept, a FrameBufferObject, is a cleaner 
>>> implementation of the idea but may not be quite as universally 
>>> supported.
>>>
>>> Having to have an invisible window is a microsoft artifact only, and not 
>>> really part of what OpenGL is about (pixelformats & such). One doesn't 
>>> need "dummy" windows on Linux.
>>
>> With NVIDIA 7x and 8x cards you may create window DC using NVIDIA
>> extension wglCreateAffinityDCNV. Initially you still need invisible 
>> window
>> to initialize OpenGL and query supported extensions but once it's done 
>> this
>> window could be disposed.
>>
>> Just keep in mind that this is affinity DC meaning that GL objects 
>> created
>> on one GPU couldn't be shared/used on the other GPU.
>>
>>> 2 notes;
>>>   pbuffers are probably usually single-buffered framebuffers
>>>   you need to destroy & recreate it if the target window size changes, 
>>> (I don't think pbuffers can be resized, but don't totally remember).
>>
>> Most likely you are right :-(
>> So you have two choices - recreate p-buffer/FBO each time or create it
>> just once "big enough" (e.g. 2560x2048) and this becomes memory/speed
>> tradeof.
>>
>> Create FBO could be costly and for some applications even time-critical
>> operation. In their latest drivers NVIDIA tweaked up the performance but
>> still it's about 80-90 mSec.
>>
>>> jbw
>>>
>>
>> Georgy
>
> O.K. thanks guys. I need compatibitily going a while back, so I'll stick 
> with the pbuffer.
> The code creates a window, checks the extensions, deletes window and 
> creates a new one with extensions, then creates pbuffer - such a large 
> amount of code!

Success! Thanks guys for the pointers. Just some extras for anybody else 
interested.
For the invisible window used to get the GL extension info I've made 4x4 as 
it isn't needed - I only use the pbuffer. Not sure if this saves memory, but 
it seemed the right thing to do.
I seen forum debates on whether "BitBlt" or "SetDIBitsToDevice" is quicker, 
but I couldn't figure out how to make the BlitBlt data from the pixels, so I 
went for the latter.

One question though, would it be faster in returning different formats?

I've used the following code to copy the buffer to the screen:-

pixels is a width*height*3 unsigned byte array.
I used GL_BGR_EXT because the Red and Blue were the wrong way around! (Well 
at least it wasn't upside down...)

wglMakeCurrent(offDC, offRenderContext);
glReadPixels( 0,0, width, height, GL_BGR_EXT, GL_UNSIGNED_BYTE, pixels);
BITMAPINFOHEADER bitmapInfo;
ZeroMemory(&bitmapInfo,sizeof(BITMAPINFOHEADER));
bitmapInfo.biSize = sizeof(BITMAPINFOHEADER);
bitmapInfo.biWidth = width;
bitmapInfo.biHeight = height;
bitmapInfo.biPlanes = 1;
bitmapInfo.biBitCount = 24
bitmapInfo.biCompression = BI_RGB;
bitmapInfo.biSizeImage = 
bitmapInfo.biWidth*bitmapInfo.biHeight*bitmapInfo.biBitCount/8;
HDC devc = GetDC(dispWnd);
SetDIBitsToDevice(devc,
        0,0,
        bitmapInfo.biWidth,
        bitmapInfo.biHeight,
        0,
        0,
        0,
        bitmapInfo.biHeight,//bitmap.bmHeight,
        pixels,
        (LPBITMAPINFO)&bitmapInfo,
        DIB_RGB_COLORS);











 

"VelociChicken" <bob@yahoob.com> wrote in message 
news:NTmHl.48359$bq4.35652@newsfe29.ams2...
>
> "VelociChicken" <bob@yahoob.com> wrote in message 
> news:pmkHl.31385$KB5.26489@newsfe11.ams2...
>>
>> "Georgy Malyshev" <x@y.z> wrote in message 
>> news:49eda831$0$22528$607ed4bc@cv.net...
>>>
>>> "jbwest" <jbwest@acm.org> wrote in message 
>>> news:49ecc4ea$0$29138$6e1ede2f@read.cnntp.org...
>>>>
>>>> "VelociChicken" <bob@yahoob.com> wrote in message 
>>>> news:m8%Gl.44105$rk7.21779@newsfe05.ams2...
>>>>> It just seems that making a new window, then adding a pbuffer to it 
>>>>> seems a bit OTT. Can't I render straight to the invisible window the 
>>>>> read the pixels from that?
>>>>> Thanks again, hopefully it will all sink in soon, it's just that its 
>>>>> starting to look over complex.
>>>>>
>>>>> Cheers,
>>>>> J
>>>>>
>>>>>
>>>>
>>>> No, you cannot render to an obscured or invisible window and expect to 
>>>> read back anything useful.
>>>> Windows have valid framebuffer contents *only*in the *visible* portions 
>>>> of them. That's why you need an offscreen
>>>> p-buffer, it *can* be rendered on and read back without any pixels 
>>>> being visible. A more modern concept, a FrameBufferObject, is a cleaner 
>>>> implementation of the idea but may not be quite as universally 
>>>> supported.
>>>>
>>>> Having to have an invisible window is a microsoft artifact only, and 
>>>> not really part of what OpenGL is about (pixelformats & such). One 
>>>> doesn't need "dummy" windows on Linux.
>>>
>>> With NVIDIA 7x and 8x cards you may create window DC using NVIDIA
>>> extension wglCreateAffinityDCNV. Initially you still need invisible 
>>> window
>>> to initialize OpenGL and query supported extensions but once it's done 
>>> this
>>> window could be disposed.
>>>
>>> Just keep in mind that this is affinity DC meaning that GL objects 
>>> created
>>> on one GPU couldn't be shared/used on the other GPU.
>>>
>>>> 2 notes;
>>>>   pbuffers are probably usually single-buffered framebuffers
>>>>   you need to destroy & recreate it if the target window size changes, 
>>>> (I don't think pbuffers can be resized, but don't totally remember).
>>>
>>> Most likely you are right :-(
>>> So you have two choices - recreate p-buffer/FBO each time or create it
>>> just once "big enough" (e.g. 2560x2048) and this becomes memory/speed
>>> tradeof.
>>>
>>> Create FBO could be costly and for some applications even time-critical
>>> operation. In their latest drivers NVIDIA tweaked up the performance but
>>> still it's about 80-90 mSec.
>>>
>>>> jbw
>>>>
>>>
>>> Georgy
>>
>> O.K. thanks guys. I need compatibitily going a while back, so I'll stick 
>> with the pbuffer.
>> The code creates a window, checks the extensions, deletes window and 
>> creates a new one with extensions, then creates pbuffer - such a large 
>> amount of code!
>
> Success! Thanks guys for the pointers. Just some extras for anybody else 
> interested.
> For the invisible window used to get the GL extension info I've made 4x4 
> as it isn't needed - I only use the pbuffer. Not sure if this saves 
> memory, but it seemed the right thing to do.
> I seen forum debates on whether "BitBlt" or "SetDIBitsToDevice" is 
> quicker, but I couldn't figure out how to make the BlitBlt data from the 
> pixels, so I went for the latter.
>
> One question though, would it be faster in returning different formats?
>
> I've used the following code to copy the buffer to the screen:-
>
> pixels is a width*height*3 unsigned byte array.
> I used GL_BGR_EXT because the Red and Blue were the wrong way around! 
> (Well at least it wasn't upside down...)
>
> wglMakeCurrent(offDC, offRenderContext);
> glReadPixels( 0,0, width, height, GL_BGR_EXT, GL_UNSIGNED_BYTE, pixels);
> BITMAPINFOHEADER bitmapInfo;
> ZeroMemory(&bitmapInfo,sizeof(BITMAPINFOHEADER));
> bitmapInfo.biSize = sizeof(BITMAPINFOHEADER);
> bitmapInfo.biWidth = width;
> bitmapInfo.biHeight = height;
> bitmapInfo.biPlanes = 1;
> bitmapInfo.biBitCount = 24
> bitmapInfo.biCompression = BI_RGB;
> bitmapInfo.biSizeImage = 
> bitmapInfo.biWidth*bitmapInfo.biHeight*bitmapInfo.biBitCount/8;
> HDC devc = GetDC(dispWnd);
> SetDIBitsToDevice(devc,
>        0,0,
>        bitmapInfo.biWidth,
>        bitmapInfo.biHeight,
>        0,
>        0,
>        0,
>        bitmapInfo.biHeight,//bitmap.bmHeight,
>        pixels,
>        (LPBITMAPINFO)&bitmapInfo,
>        DIB_RGB_COLORS);
>
>
>
>
>
>

BGRA might be faster as it's aligned better. Maybe not tho.

jbw

>
>
>
>
>
>
>
> 

"VelociChicken" <bob@yahoob.com> wrote in message 
news:NTmHl.48359$bq4.35652@newsfe29.ams2...

> I've used the following code to copy the buffer to the screen:-
>
> pixels is a width*height*3 unsigned byte array.
> I used GL_BGR_EXT because the Red and Blue were the wrong way around! 
> (Well at least it wasn't upside down...)

Yeah, that's a Windows deception - even format is called RGB actually 
windows
expects BGR stream of bytes.

Georgy