Hello,

I have a question:

When or how is a rendering context lost during normal program execution ?

I can think of two possibilities:

1. When another rendering context is made active. (wglMakeCurrent) Seems 
logical.

2. When another device context is made active ?? I am not sure... how does 
it become active ?

3. Others ??

Bye,
  Skybuck.

Am Thu, 5 Aug 2010 12:42:17 +0200
schrieb "Skybuck Flying" <IntoTheFuture@hotmail.com>:

> Hello,
>=20
> I have a question:
>=20
> When or how is a rendering context lost during normal program
> execution ?

Replace "lost" with "becomes inactive".

> I can think of two possibilities:
>=20
> 1. When another rendering context is made active. (wglMakeCurrent)
> Seems logical.

Of course. If you want to cleanly shut down all OpenGL render contexts
you do a wglMakeCurrent(hdc, NULL);
=20
> 2. When another device context is made active ?? I am not sure... how
> does it become active ?

Unlike OpenGL Windows GDI doesn't have the concept of an "active" DC.
But DCs have a reference counter, which can be increased
(GetDC, GetWindowDC, BeginPaint) and decreased (ReleaseDC, EndPaint) and
also have a state.

DCs can be either bound to visible drawables (windows), or independent
from any drawable, but not device created using CreateDC or
CreateCompatibleDC, freed with DeleteDC.

Visible drawables (windows) may have either each their own DC, or may
share a DC between them.=20

Polish up your knowledge about Window Classes...
http://msdn.microsoft.com/en-us/library/ms633574(v=3DVS.85).aspx#class_styl=
es

.... read what Microsoft has to say about OpenGL
http://msdn.microsoft.com/en-us/library/dd374293(v=3DVS.85).aspx
especially about multithreading
http://msdn.microsoft.com/en-us/library/dd374269(v=3DVS.85).aspx

.... and you might as well understand what's causing your Green Taskbar
effect.


Wolfgang

P.S.: fungus probably hates me for giving you so much information,
but I suspect that even with this truckload of information you'll still
be unable to solve it in a target-oriented way. I shall say you the
(minimum!) number of things you must get right: 3.

I expect that you may find the solution by trial and error, but that's
not for sure.

Don't expect recipes. You've went past that stage we'd have done this
for you a looong time ago. Not because we're some snooty smart asses,
we've just realized that any good advice was wasted on you.
--=20
CIP-Rechnerbetriebsgruppe
Fakult=C3=A4t f=C3=BCr Physik - LMU M=C3=BCnchen
Schellingstrasse 4, 80799 M=C3=BCnchen

On Aug 5, 1:39=A0pm, "Wolfgang.Draxinger" <Wolfgang.Draxin...@physik.uni-
muenchen.de> wrote:
>
> P.S.: fungus probably hates me for giving you so much information,

You also know what the problem is...?

You have not answered my question.

Some further questions:

1. Why does OpenGL require the DeviceContext in the call to wglMakeCurrent ? 
In other words: Why is the RenderingContext not enough ?

That question could help answering how device context and/or rendering 
contexts are lost (become inactive).

Further more I asked these questions not because of problems with the 
taskbar.

The problem is how I described it in another thread but I will repeat it 
here:

There are two opengl windows in one application, single-threaded, each 
window has it's own rendering context.

Both windows call wglMakeCurrent before they start drawing.

However something exceptional occurs.

Right after the call to wglMakeCurrent one of the windows calls a third 
window to become open.

The third window does not use OpenGL for as far as I know...

Somehow this upsets the OpenGL rendering contexts...

After the call returns... the window ends up drawing in the wrong rendering 
context and/or window ?

Could be a opengl issue, could also be a delphi issue but I don't think 
so... could be a get handle issue.

Bye,
  Skybuck.

On Thu, 5 Aug 2010 17:51:20 +0200
"Skybuck Flying" <IntoTheFuture@hotmail.com> wrote:

> You have not answered my question.
> 
> Some further questions:
> 
> 1. Why does OpenGL require the DeviceContext in the call to
> wglMakeCurrent ? In other words: Why is the RenderingContext not
> enough ?

Because a Window can have multiple device contexts. wglCreateContext is
not so much interested in the DC itself, but the window it's attached
to.

Citing the MSDN reference page on wglCreateContext:
| The wglCreateContext function creates a new OpenGL rendering
| context, which is suitable for drawing on the device referenced by
| hdc. The rendering context has the same pixel format as the device
| context.

The keyword is _suitable_. It does not mean you're bound to exactly
the DC, you're using for creation. You can wglMakeCurrent on any DC
that's sharing its key properties with the one DC used for creation. A
window can have more than one DC, and a DC can be attached to more than
one window.

The usage outline of every DC context, also with OpenGL looks
somewhat like this (except if you take some preparation that's related
to the WindowClass):

on WM_CREATE / OnCreate handler:
	hDC = GetDC(hWnd);
	hRC = wglCreateContext(hDC);
	ReleaseDC(hDC).

on WM_PAINT / OnPaint handler:
	PAINTSTRUCT ps;
	hDC  = BeginPaint(hWnd, &ps);
	wglMakeCurrent(hDC, hRC);
	GL_draw();
	EndPaint(hWnd, &ps);

Now there's one little flag you can set and if you do this, then you
can keep that one hDC variable around and don't have to release it.
Especially if you aim for high performance that's highly recommended.

I'm not going to tell you, which one it is, but I did this in the
LoadLibrary("opengl32.dll") example I wrote for you. If you read it
carefully you should find it. It might also be helpful to use a Program
like WinSpy or similar to have a look with which flags the windows of
Delphi programs are created, and comparing this with the window flags
of OpenGL programs (and I'm pretty sure the official Delphi OpenGL
bindings also take care to set the proper flags).

> That question could help answering how device context and/or
> rendering contexts are lost (become inactive).

In part, but not fully.
 
> Further more I asked these questions not because of problems with the 
> taskbar.

It is related to it. If you solve this problem, you've also solved your
taskbar problem.
 
> Right after the call to wglMakeCurrent one of the windows calls a
> third window to become open.
> 
> The third window does not use OpenGL for as far as I know...
> 
> Somehow this upsets the OpenGL rendering contexts...
> 
> After the call returns... the window ends up drawing in the wrong
> rendering context and/or window ?

Multiple windows, not exactly specified how they share resources, do
the bells begin to ring?


Wolfgang

On Aug 5, 5:51=A0pm, "Skybuck Flying" <IntoTheFut...@hotmail.com> wrote:
> You have not answered my question.
>

Really?

> That question could help answering how device context and/or rendering
> contexts are lost (become inactive).
>

We already know ... as do most other people who've
read the documentation.

On Thu, 5 Aug 2010 06:28:44 -0700 (PDT)
fungus <openglMYSOCKS@artlum.com> wrote:

> You also know what the problem is...?

You mean except the obvious, his inability to properly read perfectly
clear documentation?

I don't know what his problem is exactly, and I didn't test the .exe he
provided - I would be nuts to execute something compiled by someone who
clearly demonstrated to have absolutely no clue of anything whatsoever.
But from what he wrote in his other posts I have a very clear idea,
which things he likely is doing wrong. Each of them should be fixed,
and once he does, both his "green taskbar" and the "magically disabled
context" problems will go away.

Frankly I'm rather surprised that he managed to corrupt the taskbar.
Alas, this must be one of the cases of the battle between engineers
fool-proofing their products and the universe producing bigger fools.
So far it looks like the universe is winning.


Wolfgang

Ofcourse the CS_OWNDC flag is set.

The only difference I seen so far is:

1. Your code uses double buffering which shouldn't matter ?

2. Your code uses BeginPaint EndPaint.

3. Furthermore your code is too simple (explained further below) it only has 
one window and no dialogs/messages shown.

Concerning step 2 this is already done by Delphi.

But I did it myself just to check. I find it kinda weird
how that's apperently still necessary while the owndc flag is set ?!

Anyway the end result is:

Same problem.

ShowMessage still looses the rendering context and/or device context.

The drawing ends up in the wrong window.

I am not sure what the problem is because ShowMessage is insanely complex... 
pretty much involves the entire VCL framework/windowing system/fonts/brushes 
you name it.

I suspect the following may be happening:

Window2.BeginPaint

MakeCurrent

ShowMessage which does perhaps again:
   Window3.BeginPaint


   Window3.EndPaint

Window2.EndPaint

Now the question is:

Could nested Paint sequences like this actually cause problems ?!?

If so:

1. Is it a windows problem ?

2. Is it a delphi problem ?

3. Is it an opengl problem ?!?

Furthermore I like to remind you that your simple example is 1 window only 
and does not include showing a dialog, nor does it include potential nested 
paint sequences.

If you truely want to help out investigating this mystery and perhaps learn 
something in the process I suggest you do the following:

1. Create an application/example which creates two windows.

2. Have one window create a third window which displays a simple text 
message.

3. Then try to continue rendering opengl as normal in the other two windows.

Bye,
  Skybuck. 

Lol,

Fungus is asking if you know what the problem is because he obviously has no 
clue.

If you guys had actually any experience with "application frameworks" like 
Delphi you might have a clue.

With big stars on *might* ;) :)

None the less I have provided you guys with a mission, so you can learn from 
The Great Skybuck (tm) ;) :)

So far it seems you have learned a lot from me already ! =D

Bye,
  Skybuck =D 

I think I already figured out what's going on... unlike you fuckheads.

GDI is probably accelerated by OpenGL or a similiar driver.

Therefore ShowMessage indirectly causes my RenderingContext to be 
deactivated.

Therefore it has to be re-activated after the call to ShowMessage.

At least reactivating it seems to solve the problem.

Bye,
  Skybuck. 

Furthermore this could also explain the problem with the taskbar going 
green.

Apperently the taskbar is being hardware accelerated as well...

Since my test program's loop does not call wglMakeCurrent repeatedly for 
each iteration... it loses it's context... it starts to draw on the 
taskbar's context or so ?!?

Maybe later it somehow regains it's context... or perhaps the restoration of 
it's rendering context takes a while on windows xp 32 bit...

Strangely enough the problem does not seem to be present on windows xp x64 
pro edition... which could mean that windows xp x64 pro edition's developers 
recgonized this problem and made sure to restore any rendering contexts to 
it's previous state after gdi rendering/hardware accelerated is done.

Thus this could be a bug fix which was applied/present in windows xp x64 pro 
edition but not in the older windows xp 32 bit home edition.

Modification of my loop could prove this ;)

Time will tell ;) :)

Bye,
  Skybuck.