[EFL][WK2][WebGL] The top left side of the screen is shown inside the canvas element

• Component: WebGL
• Status: RESOLVED FIXED

[Yael]

When loading a page with webGL, the first display is of the top left side of the screen.
If there are subsequent repaints, the actual canvas will show later. In many static pages, the canvas does not show.

[Yael]

Created attachment 179664 [details]
The issue

[Viatcheslav Ostapenko]

Created attachment 181621 [details]
Patch

[WebKit Review Bot]

Comment on attachment 181621 [details]
Patch

Clearing flags on attachment: 181621

Committed r139033: <http://trac.webkit.org/changeset/139033>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Kalyan]

(In reply to comment #2)
> Created an attachment (id=181621) [details]
> Patch

Bit late here, but this is not the right place to include the swap buffer call. As we can be using either EGL or GLX. Probably the call should be in PlatformContextEfl after setting the geometry. I will try to open another issue for this.

On second thought, we differ the setgeometry calls till we actually blit the texture contents to FBO in our platformLayer(GraphicsContext3DPrivate). We eventually call swapbuffers after the blit operation anyway. So, is the issue here that the buffers are not resized properly before the blit operation happens ?? (i.e would glviewport call be enough here )

[Viatcheslav Ostapenko]

(In reply to comment #5)
> (In reply to comment #2)
> > Created an attachment (id=181621) [details] [details]
> > Patch
> 
> Bit late here, but this is not the right place to include the swap buffer call. As we can be using either EGL or GLX. Probably the call should be in PlatformContextEfl after setting the geometry. I will try to open another issue for this.

Do we have the same problem on EGL?
I thought it is Xorg specific.

> On second thought, we differ the setgeometry calls till we actually blit the 
> texture contents to FBO in our platformLayer(GraphicsContext3DPrivate).
> We eventually call swapbuffers after the blit operation anyway. So, is the 
> issue here that the buffers are not resized properly before the blit operation 
> happens ?? (i.e would glviewport call be enough here )

Mesa by default doesn't resize frame buffers on glViewport. I tried it. Get mesa sources and grep for ST_MANAGER_BROKEN_INVALIDATE . I found swapbuffers is the only way to force resize.