objarni's picture

GL.Viewport set to whole GLControl -- any shortcut?

Hi there.. A usability question.

I have just started developing an GLControl app once again.

I like that the default when it comes to perspective is ordinary Orthographic project. Then you can start drawing instantly to test that everything is working alright.

But - I just stumbled over what I think may be an ordinary mistake: the GL.Viewport() state is not set to the whole GLControl per default. It looks as if it is set to the quite arbitrary 0,0,100,100 (or close to that) per default.

From my point of view, either the GL.Viewport state for the context of the GLControl should be the 0,0 plus the GLControls Width/Height properties (initialised in Form constructor or somewhere else? I don't know), or else there should be a glControl1.FullViewport() helper method that just does:

  FullViewport() {
    GL.Viewport(0,0,Width,Height);
  }

Thoughts?


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

According to the glViewport manpage, "When a GL context is first attached to a window, width and height are set to the dimensions of that window."

The GLControl doesn't update the viewport automatically when resized - you should handle the Resize event and do that manually. It's done like this in order to play well with multiple contexts (calling MakeCurrent without you knowing would be bad). That's the idea at least - I'm open to suggestions here.

In any case, I'll be adding a Rectangle overload to GL.Viewport, so you'll be able to say:

GL.Viewport(this.ClientRectangle);
objarni's picture

Well, I haven't done any resizing. It's just a stock Windows.Forms app with a single Form, on which a single GLControl of some other size than 100x100.

I'll go recheck that statement ...

Yeah - it like I said: it's a Form with a single GLControl in it, it is sized 937x576 to be specific (resize done in Visual Designer of Visual Studio 2008).

the Fiddler's picture

Actually, the designer code simply resizes the control after its creation. Unless OpenTK starts handling the resize event (which will lead to context hell) the only solution is to handle the resize event manually.

objarni's picture

It is absolutely necessary for the application to be able to attach event handlers to the Resize event of the GLControl. (a windows program may want to behave differently eg. a model viewer may want to keep the model the same size independently of how the user resizes the window, while a game in a window may want to "zoom in" during such a resize).

So it is a tough shot -- the OpenGL manpage suggests it should be "maximized" but we cannot really do that here, can we?

the Fiddler's picture

If I understand correctly your example, the resize handler for the viewport is necessary in both cases. Keeping the model at the same size is simply a matter of setting up the correct projection.

The SimpleOpenGlControl in the Tao framework does handle the viewport automatically, though. Anyone else have an opinion on this matter?

Inertia's picture

An automatic handling might be problematic, the way I see it GLControl is most attractive to write multiple-viewport applications (modellers, editors, etc). If you want the classic split-screen with 4 views, it seems to be best practice not to create 4 GLControls, but rather creating only 1 GLControl and change GL.Viewport 4x per frame to draw the views.

objarni's picture

My example: I tried to say that yes, the Resize event should definitely be available to the application. And, from that I gathered that OpenTK should not do anything under the hood (like setting GL.Viewport when the GLControl is resized, which would resolve the issue of this thread).

It is a conflict between simplicity-of-usage (not needed to setup Viewport when developing a GLControl/Windows.Forms app with a GLControl of any size other than 100x100) and the complexities of involving some kind of automatic mechanism during a GLControl resize.

Is it possible to both have the application handle the resize event, eg. redoing perspective setup, while OpenTK manages the Viewport (setting it to the GLControls Width/Height automatically?) Of course, the app must still have the option to change the Viewport during "his" Resize handler.

If it is possible - what is the engineering / manageability price of this feature (which after all is the out-of-the-box behaviour of OpenGL-contexts as Fiddler found out in the manpages)?

the Fiddler's picture

The price comes when you try to use two GLControls at the same time: you don't know which one will be resized last, which means you end up with an undefined current context in the end.

Now that I think of it, it makes sense to cater to the simplest use-case (viewport covers the whole GLControl, unless otherwise specified) and demand the user to always call MakeCurrent when using multiple contexts. I'm trying to recall if there were other issues that complicated matters, but right now it seems that automatically calling GL.Viewport makes the most sense.

objarni's picture

Does multiple GLControls apps development require the knowledge of how to use MakeCurrent?

About simplest use case: When I design stuff, I always try to think "simple/day-to-day things should be simple-to-do, advanced things will always be advanced".

the Fiddler's picture

Does multiple GLControls apps development require the knowledge of how to use MakeCurrent?
Most definitely, yes.