Project

General

Profile

Actions

Feature #3660

open

WGLWidget's 'gl' interface sucks when it comes to potability. Please make it comatible with OpenGL ES interface

Added by Prasad Dixit over 9 years ago. Updated over 9 years ago.

Status:
New
Priority:
High
Assignee:
-
Target version:
Start date:
11/11/2014
Due date:
% Done:

0%

Estimated time:

Description

Problem: I found myself writing a wrapper for WGLWidget because I also have code base for a 3D application written using OpenGL ES. I am trying to port it to Wt but WGLWidget's functions don't have 1-1 mapping with OpenGL ES ('gl' prefix for enums and functions is dropped. Functions parameters are different in some cases). As we are developing Desktop/mobile and Web app simultaneously, it is not a one time port. It will be a continuous work and not having 1-1 mapping with OpenGL ES is a going to be a inefficient and will result in unnecessary waste of time and maintenance overhead.

Wt is a C toolkit for Web closely emulating Qt. That being said, I should be able to port code written in C, OpenGL ES, and Qt with as minimal modification as possible. That is what make Wt attractive to me. Current interface of WGLWidget breaks that 'promise'.

As Wt becomes more popular (which I hope it will), there will be many developers who will find themselves in a similar situation as me. I hope Wt team takes notice of my concern. I think Qt's QGLWidget has done its OpenGL ES interface smart and right. I hope Wt's WGLWidget offers similar interface and developers don't need to develop there own wrappers.

Possible Solution: Wt can look into Google's ANGLE (http://en.wikipedia.org/wiki/ANGLE_(software))). ANGLE (Almost Native Graphics Layer Engine) is an open source, zlib-licensed graphics engine abstraction layer developed by Google.[1] The API is mainly designed to bring high performance OpenGL compatibility to Windows desktops and to Web Browsers such as Google Chromium by translating calls to Direct3D, which has much better driver support.

Qt uses ANGLE to make QGLWidget work on Windows in absence of OpenGL drives by mapping OpenGL calls equivalent Direct3D calls. (See: http://qt-project.org/wiki/Qt-5-on-Windows-ANGLE-and-OpenGL). For WGLWiddget similar mechanism can be used. Instead of mapping to Direct3D calls it should map to WebGL calls.

Also see: 1. http://redmine.webtoolkit.eu/issues/3606#change-10412

  1. http://redmine.webtoolkit.eu/issues/2305#change-10415
  2. http://redmine.webtoolkit.eu/boards/2/topics/8423?r=9983#message-9983

I am begging you. Please implement it. It will make Wt a better toolkit and life of lot of developers easier.

Thank you!

Actions #1

Updated by Prasad Dixit over 9 years ago

From WIKI: ANGLE is currently used in a number of programs and software.

-Chromium (web browser) and Google Chrome.[6] Chrome uses ANGLE not only for WebGL, but also for its implementation of the 2D HTML5 canvas and for the graphics layer of the Google Native -Client (which is OpenGL ES 2.0 compatible).[5]

-Firefox uses ANGLE for as the default WebGL backend on Windows[6]

-Qt 5 uses ANGLE as the default renderer for its OpenGL ES 2.0 API wrapper and other Qt elements which use it on Windows[7]

Actions #2

Updated by Wim Dumon over 9 years ago

Hey,

I'm open for suggestions, but I'm not sure if this is technologically feasible. A WGLWidget is intended to record a kind of playlist that can be executed on the client without server-side interaction when e.g. a transformation matrix or some other uniform is modified, I'm not sure if we can simply support the entire API in an efficient way.

BR,

Wim.

Actions #3

Updated by Prasad Dixit over 9 years ago

Hi Wim,

I am glad that you are open to suggestions. As I mentioned in other posts on this forum regarding this topic, I understand there are bound to be some differences and there might not be exact 1-1 mapping to OpenGL ES API because some part needs to be executed on client and some on server but what I don't understand is why it is not technically feasible to rename 'gl' function names and enums in WGLWidget class to be consistent with OpenGL ES API. That itself will be huge favor to Wt's users who are porting OpenGL ES code to Wt/WebGL.

Try to port any OpenGL ES based code to Wt and you will understand my pain point and it is absolutely avoidable.

Thank you!

-Prasad

Actions #4

Updated by Prasad Dixit over 9 years ago

@ but I'm not sure if this is technologically feasible.

Hi Wim,

I think it should be feasible and it seems it has already been successfully attempted by ReWeb3D. May be you can look at ReWeb3D https://github.com/ReWeb3D/wtgles2

From ReWeb3D's Read Me:

\"ReWeb3D is a C framework to bring 3D rendering of OpenGLES2 applications to web applications, using WebGL. It consists of an adapted version of Wt and the wtgles2 wrapper library. It has been tested successfully with OpenSceneGraph and osgEarth applications.

How does it work?

OpenGLES2 is a subset of OpenGL developed especially for mobile and embedded devices. It does not provide "fixed functions" of OpenGL 2 and below, but is very close to WebGL, an OpenGL API for web browsers (Javascript). ReWeb3D provides an OpenGLES2 implementation that you can link your application to. If you start the application, OpenGLES2 calls are captured and serialized as WebGL calls in an HTML page which is served over HTTP. The browser loads this page and renders the content of your application.

\"

From long term development using Wt as a primary framework, I prefer such solution to be part of Wt itself rather than relying on 3rd party or developing our own own wrappers Instead of using 3rd party

I hope it helps!

-Prasad

Actions

Also available in: Atom PDF