Bug 166425 - Move GraphicsContext3DWin to GraphicsContext3DOpenGLES
Summary: Move GraphicsContext3DWin to GraphicsContext3DOpenGLES
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alex Christensen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-22 11:46 PST by Alex Christensen
Modified: 2017-01-03 10:43 PST (History)
10 users (show)

See Also:


Attachments
Patch (15.22 KB, patch)
2016-12-22 15:11 PST, Alex Christensen
thorton: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Christensen 2016-12-22 11:46:27 PST
Move GraphicsContext3DWin to GraphicsContext3DOpenGLES
Comment 1 Alex Christensen 2016-12-22 15:11:25 PST
Created attachment 297679 [details]
Patch
Comment 2 Alex Christensen 2016-12-22 16:33:22 PST
http://trac.webkit.org/changeset/210123
Comment 3 Michael Catanzaro 2016-12-22 17:06:24 PST
Regarding the commit message. Please talk to the relevant GTK devs (CCing several) about this before working on it as I highly doubt this would be acceptable for us; we surely want the system GLES from mesa, not ANGLE's?
Comment 4 Alex Christensen 2016-12-22 17:18:00 PST
Don't worry, ANGLE's GLES "implementation" is just a checked wrapper and would use the system GLES as its backend.  For example, a call to getActiveAttrib from JavaScript currently does checks in GraphicsContext3D::getActiveAttrib and GraphicsContext3D::getActiveAttribImpl and then calls ::glGetActiveAttrib which calls whatever OpenGL/OpenGLES implementation the system has.  With the upcoming architecture, a call to getActiveAttrib would call ANGLE's gl::GetActiveAttrib, which would do checks similar to what we have in GraphicsContext3D::getActiveAttrib and GraphicsContext3D::getActiveAttribImpl inside of ANGLE and then ANGLE would call the system's ::glGetActiveAttrib.  I have a proof of concept working on Mac.  It's pretty terrible right now, but once it gets in better condition I'll show it to Žan et al.
Comment 5 Michael Catanzaro 2016-12-22 17:49:52 PST
OK, that sounds fine indeed!
Comment 6 Alex Christensen 2016-12-22 17:59:19 PST
I have no idea how this will work with wayland, but I'm hoping Žan can help out with that once I have something working cleanly and passing more than the most basic of tests.
Comment 7 Carlos Garcia Campos 2016-12-23 02:03:51 PST
(In reply to comment #4)
> Don't worry, ANGLE's GLES "implementation" is just a checked wrapper and
> would use the system GLES as its backend.  For example, a call to
> getActiveAttrib from JavaScript currently does checks in
> GraphicsContext3D::getActiveAttrib and
> GraphicsContext3D::getActiveAttribImpl and then calls ::glGetActiveAttrib
> which calls whatever OpenGL/OpenGLES implementation the system has.  With
> the upcoming architecture, a call to getActiveAttrib would call ANGLE's
> gl::GetActiveAttrib, which would do checks similar to what we have in
> GraphicsContext3D::getActiveAttrib and
> GraphicsContext3D::getActiveAttribImpl inside of ANGLE and then ANGLE would
> call the system's ::glGetActiveAttrib.  I have a proof of concept working on
> Mac.  It's pretty terrible right now, but once it gets in better condition
> I'll show it to Žan et al.

That's probably ok, but need to either never include eglplatform.h from ANGLE or update it, because the eglplatform.h from current ANGLE doesn't have the Wayland types.
Comment 8 Alex Christensen 2017-01-03 10:43:11 PST
We can put whatever we want in our copy of the ANGLE headers, but that sounds like something the ANGLE project would be interested in.  You could probably push a change to https://github.com/google/angle/blob/master/include/EGL/eglplatform.h