On 15.01.2010 09:52, Michel Dänzer wrote: > On Fri, 2010-01-15 at 16:32 +0800, Chia-I Wu wrote: > >> 2010/1/15 Michel Dänzer <mic...@daenzer.net>: >> >>> On Fri, 2010-01-15 at 10:48 +0800, Chia-I Wu wrote: >>> >>>> On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz <ja...@vmware.com> >>>> wrote: >>>> >>>>> Some things that needs to worked out about this interface is how to handle >>>>> glViewport vs DRI2, since the code in glViewport needs to force a update >>>>> of >>>>> the buffers in DRI2 but not for other state trackers. If we can some how >>>>> work around the need to force a update in a way that works on old servers >>>>> that would be great, but I doubt that can be done. >>>>> >>>> With the mesa/st having access to the new st_framebuffer/sm_surface, it can >>>> call validate upon glViewport. Does that suffice? >>>> I am curious about this part too. How often does DRI2GetBuffers be called >>>> in >>>> DRI2 drivers? >>>> >>> Currently, it's basically called on every glXMake*Current or glViewport >>> call, as there's no other reliable way to know when the buffer size >>> might have changed. Maybe at some point there will be a DRI2 event to >>> help with this. >>> Something I keep pointing out though is that ideally we want to avoid >>> calling DRI2GetBuffers() 'in the middle of a frame'. Once we've started >>> emitting drawing commands for a given set of DRI2 buffers, we should >>> stick to them until a buffer swap / frontbuffer flush. DRI2GetBuffers() >>> should only be called on a glXMake*Current or glViewport call if there's >>> been no drawing since the last buffer swap / frontbuffer flush (and in >>> the future maybe only if there's been no DRI2 event to signal it needs >>> to be called). >>> >> Thanks for the info. >> >> It seems OpenVG has no glViewport equivalent (correct me if I am wrong). >> Will >> it be an issue with current design? >> > Possibly. When glViewport was chosen for this I did point out the > potential problem with other APIs. > > >> If an OpenGL application does not call glViewport upon window resize, is >> it consider an application bug? >> > Yes, the OpenGL viewport isn't automatically adapted on a window resize. > > So, why don't we just make it an application bug if an app doesn't call glXMakeCurrent (and corresponding functions for other APIs) on window resize ? glut and SDL already do it ... True, some apps that use glX directly will be broken, but ... that happens.
GLX_UGLY_VIEWPORT_HACK_FOR_DRI2=1 gnome-shell Fine, I'll be silent now until I've familiarized with the DRI2 code and understood why it's so difficult to send a window resize event. >> For both reasons, DRI2GetBuffers is called on every buffer swap/flush front >> in >> egl_g3d. If this is overkill, do you have any suggestion? >> > It's overkill as long as the window size doesn't change but at the same > time possibly insufficient when it does. Unfortunately, I'm not familiar > enough with EGL to make specific suggestions for a solution there. > > > >>>> In egl_g3d, it is indirectly called in every eglSwapBuffers and >>>> flush_frontbuffer. >>>> >>> That probably won't be enough for apps which don't render frames >>> continuously but only on demand: >>> buffer swap / frontbuffer flush -- DRI2GetBuffers -- window resize -- >>> render frame: whoops, stale DRI2 buffer size >>> >> That's right. That is/was another reason I want to hook >> "winsys->update_buffer". But with the new st_api.h, which I am working >> toward >> to, the state tracker may "validate" the drawable itself when glViewport is >> called. I think it solves the problem, right? >> > I'm not familiar with all the details, but it sounds like it might. > > > ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
