Created attachment 84295 [details] Sample code that reproduces the problem. In the attached sample code, a window is created with 100x100. However, after resizing it with "i" keyboard input to 200x200, changing the viewport (with glViewport), and drawing its content again, the content is clipped with the old 100x100 size. Uncommenting line 48 will remove the bug, as if it was causing mesa to "flush" the viewport size. I noticed this on EFL (Enlightenment Foundation Libraries), both on GL X11 and Wayland EGL backends. This bug only happens on mesa from git, it seems that there's no bug on 9.1.6. I checked bug #29984, it's similar, but I still have the problem. Running on Fedora 19.
Which driver are you using (the output of glxinfo would be helpful)?
I can't find it on the glxinfo output, but I'm attaching it anyway. Is there any other way to know, or any other debug that I can attach?
Created attachment 84345 [details] glxinfo output
That's Ivybridge (i965).
Any progress made on a resolution?
This issue still exists on latest tips in master and 10.0 branches (as of today): mesa (master) heads/master-0-gf9cfe5c mesa (10.0) heads/10.0-0-g6f7da01
(In reply to comment #6) > This issue still exists on latest tips in master and 10.0 branches (as of > today): > > mesa (master) heads/master-0-gf9cfe5c > mesa (10.0) heads/10.0-0-g6f7da01 Ok, I can't seem to duplicate the issue with the attached test case with the aforementioned commits... but I still see the issue in EFL.
(In reply to comment #7) > (In reply to comment #6) > > This issue still exists on latest tips in master and 10.0 branches (as of > > today): > > > > mesa (master) heads/master-0-gf9cfe5c > > mesa (10.0) heads/10.0-0-g6f7da01 > > Ok, I can't seem to duplicate the issue with the attached test case with the > aforementioned commits... but I still see the issue in EFL. I take that back... I was able to duplicate *sometimes*.
The hope is that EFL 1.8 will be integrated into Tizen in January... however this bug impacts EFL 1.8 quality on its wayland egl engine. Therefore, raising importance to "high". Preferably, the fix should be backported to the 9.2 branch.
This seems to work fine for me with the latest Mesa. Feel free to reopen if this is still a problem for you.
(In reply to comment #10) > This seems to work fine for me with the latest Mesa. Feel free to reopen if > this is still a problem for you. I think this was originally reported based on a side-effect it had on EFL... https://phab.enlightenment.org/T493 Unfortunately, the EFL issue still remains (even with latest mesa). So perhaps the EFL bug isn't related to this issue at all. Any ideas why we are seeing the problem in EFL?
Created attachment 103044 [details] clear color does not fill new viewport size The problem is that the GL color buffer does not fill the GL viewport after it's been resized. That is, after calling glViewport(...) the background color goes black, and in the more extreme case the original clear color remains in the portion of the previous viewport size giving the illusion of being clipped (as seen in my attached image). If you modify the glClearColor(...) in the sample test code to be something other than black, then the problem becomes obvious. If then you add a glClear(GL_COLOR_BUFFER_BIT) after the call to glViewport(...), then the problem goes away. The question is, is it the responsibility of the GL client program to make a call to glClear after executing glViewport, or is Mesa supposed to handle this for you? The EFL developers indicate that this is only a problem on Intel platforms.
(In reply to comment #12) > If then you add a glClear(GL_COLOR_BUFFER_BIT) after the call to > glViewport(...), then the problem goes away. > > The question is, is it the responsibility of the GL client program to make a > call to glClear after executing glViewport, [...] It is, if the GL client program wants the new viewport size to be filled with the clear colour.
Created attachment 104458 [details] modified weston-simple-egl (courtesy of antognolli)
The bug on EFL side has been closed for a while, so I think it's fine to close this one too.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.