--- Brian Paul <[EMAIL PROTECTED]> wrote:
- snip -
what exactly is a cliprect? I've read over the FAQ and the source
and
it seems to define a clipping region if you have overlapping
windows.
That's basically it. The cliprect list is a list of non-overlapping 2D rectangles that define the region of a window which can be
rendered into. A fully visible window will have one cliprect which matches
the window size.
AH... ok, that makes sense. sort of like a viewport into the 3D output.
I'm not sure I understand how this fits with the maximum size of the 3D context.
A rendering context has a maximum viewport size (GL_MAX_VIEWPORT) but
the window/canvas can be larger. Remember, GL contexts and windows/drawables are distincly different things.
Ok... I think I need some clarification. if you are running two instances of glxgears let's say, would each 3D window be a separate context?
Windows can't "be" contexts.
The glxgears demo creates one window and one GLX context. When you run multiple instances of glxgears there are multiple GLX contexts but they're not aware of each other (just like any Unix process).
the windows would then be a viewport into that context or am I way off?
You're way off. A rendering context contains the current OpenGL state (current color, blend mode, texture modes, transformation matrices, etc). This information is not per-window state.
In my application I can create a rendering context and use it to render into any number of windows. The glXMakeCurrent() call binds a rendering context to a window (for the calling thread).
A rendering context can only be bound to one (or zero) windows at any given instant.
Only one rendering context can be "current" at a time (for each thread).
Or are contexts app specific?
A GL rendering context is explicitly created by applications by calling glXCreateContext(), for example. Creating a window does not create a rendering context.
you might have an app that displays two separate 3D windows would that be one context with two windows?
Not necessarily. If an application opens multiple 3D windows, it may use any number (>1) of rendering contexts to draw into them. But for a single-threaded program, only one can be current/active at any instant.
BTW, GLUT creates one rendering context for each window, so there happens to be a one-to-one correspondence between contexts and windows in that case.
It seems that a lot of people don't understand the distinction between rendering contexts and windows. Hopefully it's getting clearer now.
I assume each 3D context has some number of clip rects associated with it (at least one?).
A context doesn't have clip rects. Windows have cliprects.
> Does the cliprect define the 3D region?
It defines the 2D region of a window which it's legal to render into (i.e. the OpenGL "ownership" test).
ok.
so basically, the code would have to check the size of the 3D region requested and if it was wider or taller than 2048, it would allocate an additional cliprect?
Where does 2048 come from? There's no window size limits that I'm aware of. There is a GL viewport size limit, as mentioned above.
the radeon scissor registers are only 12 bits apparently, hence the max cliprect is 2048x2048. Several users have noted that if they create a 3D window of greater than 2048, it only displays stuff up to 2048.
Ok, that's a problem. I wasn't aware of that hardware limitation, but I'm not surprised by it. Windows wider than 2K pixels arent' too common yet.
I guess I can't quite see how all this is supposed to work together. Also what source files should I look in to mess with this? I apologizer if I'm getting the terms mixed up.
The DRI drivers query the cliprect list for a window with the XF86DRIGetDrawableInfo() function (defined in
xc/lib/GL/dri/XF86dri.c)
Oh! I think it's starting to come together in my head. basically what I need to do is add a cliprect if the window is larger than 2048 in either dimension. now, since this would be radeon specific, which radeon file should I look in...or...I guess I should check the radeon driver and when it calls XF86DRIGetDrawableInfo() check the size of each cliprect. if it's larger then 2048, then I'd delete that cliprect and replace it with two or more smaller ones or change the size of the offending cliprect and add another. is this sort of behavior allowed at that stage?
I _think_ that could be done. I'd have to study the code for a while to fully understand the issues.
You better check if there are any other hardware limitations (such as scanline stride or pitch) before going too far. For example, if the scanline stride is limited to 2K pixels you won't be able to go any wider.
Good luck.
-Brian
------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
