Hi, I time most of my code as i go and i have discovered that wglMakeCurrent
takes more than 20 times as long to execute as it takes to clear the window
and draw a simple triangle. It consistently takes about 2% of my 1.5Ghz
athalon. Is that normal? If not any ideas what i may have done wrong?

Sorry for the flood of stoopid questions,  ;-)

chris

I was switching in and out at the start and end of processing the WM_PAINT
message.

I decided to test it on another computer and my old Celeron 400 manages to
switch it in about 0.1% of my CPU time so I think somthing is wrong.

thanks,

chris


"JB West" <jbwest@NOSPAM_acm.org> wrote in message
news:cHudnZGeev0HOmqjXTWJhQ@comcast.com...
> do you have to call it that much? Are you switching contexts ?
>
> "chris jones" <flak@clara.co.uk> wrote in message
> news:1056406021.50778.2@demeter.uk.clara.net...
> > Hi, I time most of my code as i go and i have discovered that
> wglMakeCurrent
> > takes more than 20 times as long to execute as it takes to clear the
> window
> > and draw a simple triangle. It consistently takes about 2% of my 1.5Ghz
> > athalon. Is that normal? If not any ideas what i may have done wrong?
> >
> > Sorry for the flood of stoopid questions,  ;-)
> >
> > chris
> >
> >
> >
> >
>
>

After some searching in MSDN i have found an article that says
wglMakeCurrent has some serious overhead on Windows NT, so that means 2000
and Xp too. Which explains why my other computer (win98) has no problem.
This realy screws things up if you have multiple windows cause 2% cpu
overhead for every context switch is soon going to add up. I feel pretty
frustrated now. Why is everything on Windows so much bloody effort....

chris

"chris jones" <flak@clara.co.uk> wrote in message
news:1056462696.92742.0@iris.uk.clara.net...
> I was switching in and out at the start and end of processing the WM_PAINT
> message.
>
> I decided to test it on another computer and my old Celeron 400 manages to
> switch it in about 0.1% of my CPU time so I think somthing is wrong.
>
> thanks,
>
> chris
>
>
> "JB West" <jbwest@NOSPAM_acm.org> wrote in message
> news:cHudnZGeev0HOmqjXTWJhQ@comcast.com...
> > do you have to call it that much? Are you switching contexts ?
> >
> > "chris jones" <flak@clara.co.uk> wrote in message
> > news:1056406021.50778.2@demeter.uk.clara.net...
> > > Hi, I time most of my code as i go and i have discovered that
> > wglMakeCurrent
> > > takes more than 20 times as long to execute as it takes to clear the
> > window
> > > and draw a simple triangle. It consistently takes about 2% of my
1.5Ghz
> > > athalon. Is that normal? If not any ideas what i may have done wrong?
> > >
> > > Sorry for the flood of stoopid questions,  ;-)
> > >
> > > chris
> > >
> > >
> > >
> > >
> >
> >
>
>

http://msdn.microsoft.com/library/en-us/dnopen/html/msdn_opengl9.asp?frame=t
rue

its at the bottom of the page under 'Putting it all together',

Ive quoted it here for anyone else interested.....
"Rest assured, you can follow your ingrained desire to delete the DC
immediately after use. Figure 6 illustrates this. The rendering context is
created in the response to WM_CREATE, and the DC used to create the context
is released or deleted. It is not until the response to WM_PAINT that the
rendering context is bound to a device context, in this case the Paint DC.
It is important to note that this way of doing things is quite expensive.
Making the context current is not trivial. The point to be made here is that
a rendering context must be bound to a DC before OpenGL drawing can take
place. You decide where and what DC you are going to bind to the rendering
context (as long as the DC has the same pixel format as that used to create
the rendering context)."

chris

"Greg Chien" <gchien@n.o.S.p.a.m.protodesign-inc.com> wrote in message
news:6Q%Ja.10491$nG.12575@rwcrnsc51.ops.asp.att.net...
> "chris jones" wrote
> > After some searching in MSDN i have found an article that says
> > wglMakeCurrent has some serious overhead on Windows NT, so
> > that means 2000 and Xp too.
>
> Can you provide a link to the article?  I searched "wglMakeCurrent" but
> could not find the specific one.
>
> --
> TIA,
> Greg Chien
> e-mail: remove n.o.S.p.a.m.
> http://protodesign-inc.com
>
>

chris jones wrote:
>>I'm not sure I follow that leap of logic....
> 
> Windows 2000 and Xp are based on NT arnt they?
> 

As far as marketing is concerned, yes.

As far as code goes, only Microsoft knows for sure,
but NT and XP are totally different as regards graphics
and sound, eg. NT canot support DirectX in hardware.

> i would guese that Microsoft has not updated
> its OpenGl architechre in least five years either

Correct.

> so it is probably still
> relevant, at least it explains my experiences,
> 

Windows OpenGL is basically just a load of hooks
into the graphics driver so I don't think anything
can ever be generalized as "always slow"*. A particular
driver/card combination can be slow, but that doesn't
mean they all are.




* Unless you're talking about the built-in software
renderer.


-- 
<\___/>          For email, remove my socks.
/ O O \
\_____/  FTB.    Why isn't there mouse-flavored cat food?

Hi Fungus,

ive been tinkering for a couple of hours and i have solved the problem but i
have no idea why. Basicly i had the pixel format flags set to...

PFD_DRAW_TO_WINDOW or PFD_SUPPORT_OPENGL;

but if i add -- PFD_DRAW_TO_BITMAP

it goes 200 times faster, the wglMakeCurrent time is now completly
insignificant. I checked it a few times and i got consistent results, i even
restarted my computer just incase. What i dont understand is why it should
make any diferance,

cheers,

chris






"fungus" <openglMY@SOCKSartlum.com> wrote in message
news:Re1Ka.1473292$u6.2493300@telenews.teleline.es...
> chris jones wrote:
> >>I'm not sure I follow that leap of logic....
> >
> > Windows 2000 and Xp are based on NT arnt they?
> >
>
> As far as marketing is concerned, yes.
>
> As far as code goes, only Microsoft knows for sure,
> but NT and XP are totally different as regards graphics
> and sound, eg. NT canot support DirectX in hardware.
>
> > i would guese that Microsoft has not updated
> > its OpenGl architechre in least five years either
>
> Correct.
>
> > so it is probably still
> > relevant, at least it explains my experiences,
> >
>
> Windows OpenGL is basically just a load of hooks
> into the graphics driver so I don't think anything
> can ever be generalized as "always slow"*. A particular
> driver/card combination can be slow, but that doesn't
> mean they all are.
>
>
>
>
> * Unless you're talking about the built-in software
> renderer.
>
>
> --
> <\___/>          For email, remove my socks.
> / O O \
> \_____/  FTB.    Why isn't there mouse-flavored cat food?
>
>
>

By % CPU time i mean %Cpu usage per second, I mesure cpu cycles using RTSD
btw,

it was definatly the call to wglMakeCurent cause i was just timing that
single function, usualy i start by timimg a big chunk of code and then
narrow it down to identify the bottlenecks.

So I dont know if you read my other post but i have identified that setting
PFD_DRAW_TO_BITMAP for the DC seems to fix the problem but i realy dont
understand why. It realy is just that one flag...

heres the code...

resetCpuClock();
wglMakeCurrent(dc, glcontext);
clk := getCpuClock();
logError(wglMakeCurrent time - ' + FloatToStr( clk / 15000000 ) + '%' );

with PFD_DRAW_TO_BITMAP set i get : 0.013% very little variation
with PFD_DRAW_TO_BITMAP clear i get : 2% give or take 0.3%

cheers,

chris


"Greg Chien" <gchien@n.o.S.p.a.m.protodesign-inc.com> wrote in message
news:A22Ka.11345$nG.12711@rwcrnsc51.ops.asp.att.net...
> "chris jones" wrote
> > Ive quoted it here for anyone else interested.....
> > "Rest assured, you can follow your ingrained desire to delete the DC
> > immediately after use.
> [snip]
>
> It explains that creating hDC and hRC may be expensive; therefore, the
> first method is suggested.  I don't think wglMakeCurrent() is the problem,
> though.  You can actually store the handles of hDC and hRC, and use them
> when processing WM_PAINT messages within the message loop.  Besides, an
> application may need to render 3D graphics to various output, such as
> print/preview, copy to clipboard, export to image files, etc.  The
> wglMakeCurrent() function is needed in these situations (as we do), and I
> haven't found any major slowdown as you observed on NT/2K/XP.  BTW, what
> do you mean by 2% or 0.1% of your CPU time?
>
> --
> Best Regards,
> Greg Chien
> e-mail: remove n.o.S.p.a.m.
> http://protodesign-inc.com
>
>

Yes it results in diferant drivers! But the slow conext switch one is

Vendor   - NVIDIA Corporation
Renderer - GeForce4 Ti 4200 with AGP8X/AGP
Version - 1.4.0

the fast conext switch one is

Vendor   - Microsoft Corporation
Renderer - GDI Generic
Version - 1.1.0

For time to actualy paint the GDI Generic is about 30%  slower than the
GeForce, not much but thats only timing a glClear + a big triangle. I dont
what it will be with somthing more complicated..

I take it the MS renderer is Software but it will delegate to hardware
implemented GDI calls if it is somthing they can do?

cheers,

chris


"Jeff Duncan" <jeffery@altsoftware.com> wrote in message
news:0JhKa.605$Gf3.1972@tor-nn1.netcom.ca...
> "chris jones" <flak@clara.co.uk> wrote in message
> news:1056493731.21024.0@despina.uk.clara.net...
> > So I dont know if you read my other post but i have identified that
> setting
> > PFD_DRAW_TO_BITMAP for the DC seems to fix the problem but i realy dont
> > understand why. It realy is just that one flag...
>
> Does the driver in use change when you specify 'draw to bitmap'?  Check
the
> vendor string in both configurations.
>
> -- Jeff
>
>

just to add more info....

is there any diferance bewteen openGl v1.1 and v1.4 that might be causing
the slow context switch? I have now noticed that since i added my window
clipping using glScissor, the NVIDIA driver clears the whole window a dark
green color, ie parts outside the clip get cleared dark green. It even gets
cleared when i have nothing but...

wglMakeCurrent(dc,glc);
wglMakeCurrent(0,0);

Also I just tested the PFD_GENERIC_ACCELERATED and PFD_GENERIC_FORMAT flags
as explained in the MS docs and the MS GDI Generic ic showing up as hardware
accelerated.

cheers,

chris


"chris jones" <flak@clara.co.uk> wrote in message
news:1056561650.18895.0@iris.uk.clara.net...
> Yes it results in diferant drivers! But the slow conext switch one is
>
> Vendor   - NVIDIA Corporation
> Renderer - GeForce4 Ti 4200 with AGP8X/AGP
> Version - 1.4.0
>
> the fast conext switch one is
>
> Vendor   - Microsoft Corporation
> Renderer - GDI Generic
> Version - 1.1.0
>
> For time to actualy paint the GDI Generic is about 30%  slower than the
> GeForce, not much but thats only timing a glClear + a big triangle. I dont
> what it will be with somthing more complicated..
>
> I take it the MS renderer is Software but it will delegate to hardware
> implemented GDI calls if it is somthing they can do?
>
> cheers,
>
> chris
>
>
> "Jeff Duncan" <jeffery@altsoftware.com> wrote in message
> news:0JhKa.605$Gf3.1972@tor-nn1.netcom.ca...
> > "chris jones" <flak@clara.co.uk> wrote in message
> > news:1056493731.21024.0@despina.uk.clara.net...
> > > So I dont know if you read my other post but i have identified that
> > setting
> > > PFD_DRAW_TO_BITMAP for the DC seems to fix the problem but i realy
dont
> > > understand why. It realy is just that one flag...
> >
> > Does the driver in use change when you specify 'draw to bitmap'?  Check
> the
> > vendor string in both configurations.
> >
> > -- Jeff
> >
> >
>
>
>
>
>
>