WebGL app Figma

[Alecazam]

Just wanted to thank all of the hard work on making WebGL a reality on so many browsers, and for all of the help and suggestions that I received on these forums.  We've been trying to push the boundaries of what you can do creating a professional design tool in the browser with WebGL.   Just thought many of you might be interested.  Evan Wallace and I have been working on the rendering engine for two years, and it was quite a learning experience.  Hope to share more about some of our rendering approaches once time slows down.

[Kenneth Russell]

Very cool! Congratulations on your launch. I hope that it goes well and that you guys are a big success.

Since you didn't mention any stories, here are a couple:

http://www.businesswire.com/news/home/20151203005753/en/Figma-Introduces-World%E2%80%99s-Browser-Based-Professional-Grade-Tool

http://techcrunch.com/2015/12/03/figma-vs-goliath/

and your company's site:

https://www.figma.com/

I realize it's probably been a struggle to get your algorithms to work within WebGL's relatively limited feature set, but I do hope that the work we've done to ensure consistent behaviors across platforms has made your life easier.

Keep us posted on your progress!

-Ken

On Thu, Dec 3, 2015 at 12:39 PM, Alecazam <al...@figma.com> wrote:

Just wanted to thank all of the hard work on making WebGL a reality on so many browsers, and for all of the help and suggestions that I received on these forums.  We've been trying to push the boundaries of what you can do creating a professional design tool in the browser with WebGL.   Just thought many of you might be interested.  Evan Wallace and I have been working on the rendering engine for two years, and it was quite a learning experience.  Hope to share more about some of our rendering approaches once time slows down.

--
You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alecazam]

Thanks Ken.   The landscape for the GPU is changing so quickly with VR and the need for higher frame rates.   That bodes well for the 2D applications like ours.  

I'm excited about WebGL 2, but was surprised when it stopped working on my 2010 PowerMac with Nvidia 330m.  I felt like that was a reasonable minspec.  I've also worked a lot with console APIs, and wonder how the web will incorporate low-level DX12/Metal into a secure environment.   A lot of the issues that remain for web apps aren't even WebGL related.  WebGL seems pretty solid at this point, but could always expose more of the desktop features.

One issues I see with web apps are a lack of consistent support for file and directory handling (Safari still doesn't have <a href=blob download> support.   And the dialogs that do present themselves are not easily configured.  As much as I appreciate a sandbox, it does get in the way if you still want to preserve files locally on your drive.    Dropbox and other file/folder services basically route around the browser sandbox anyways.  

The second big issue is pinch-zoom control.  Safari and Firefox still don't have the pinch-zoom-to-ctrl-mousewheel intercept that Chrome does.   Safari with our app and with Google Maps is just not the same experience you find elsewhere.  I've communicated with Dean Jackson about that, and know it's on their rader.

The third issue is being able to override the color-space and srgb conversions on images.   This is trivial thing to do at the parser, but none of the browsers allow this.   That means images import differently on each browser when they do and don't support the conversions.  It would be better to be able to just tell the image decoders to hand back the raw bits. 

[Kenneth Russell]

On Sun, Dec 6, 2015 at 11:05 AM, Alecazam <al...@figma.com> wrote:

Thanks Ken.   The landscape for the GPU is changing so quickly with VR and the need for higher frame rates.   That bodes well for the 2D applications like ours.  

I'm excited about WebGL 2, but was surprised when it stopped working on my 2010 PowerMac with Nvidia 330m.  I felt like that was a reasonable minspec.

Could you email me the contents of about:gpu from your machine off-list when the --enable-unsafe-es3-apis argument is passed to Chrome?

I can't promise that we can make this work. I don't remember the minimum OpenGL version we require in order to provide ES 3.0 in Chrome. https://developer.apple.com/opengl/capabilities/ indicates your machine only supports OpenGL 3.3, where newer machines support 4.1.

 

 I've also worked a lot with console APIs, and wonder how the web will incorporate low-level DX12/Metal into a secure environment.   A lot of the issues that remain for web apps aren't even WebGL related.  WebGL seems pretty solid at this point, but could always expose more of the desktop features.

One issues I see with web apps are a lack of consistent support for file and directory handling (Safari still doesn't have <a href=blob download> support.   And the dialogs that do present themselves are not easily configured.  As much as I appreciate a sandbox, it does get in the way if you still want to preserve files locally on your drive.    Dropbox and other file/folder services basically route around the browser sandbox anyways.  

Please file bugs against browsers, including small test cases, to get these feature gaps filled. We can try to help to point out the highest-priority issues affecting apps like yours.

 

The second big issue is pinch-zoom control.  Safari and Firefox still don't have the pinch-zoom-to-ctrl-mousewheel intercept that Chrome does.   Safari with our app and with Google Maps is just not the same experience you find elsewhere.  I've communicated with Dean Jackson about that, and know it's on their rader.

The third issue is being able to override the color-space and srgb conversions on images.   This is trivial thing to do at the parser, but none of the browsers allow this.   That means images import differently on each browser when they do and don't support the conversions.  It would be better to be able to just tell the image decoders to hand back the raw bits. 

The UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameter is supposed to provide this control. Setting it to NONE is supposed to give you back the raw bits. Does this not work?

Also, ImageBitmap is being shipped soon in Chrome because of some nice work by the Canvas team and soon it will support https://wiki.whatwg.org/wiki/ImageBitmap_Options which will basically let you get lower-level access to the decoder, without going through an HTMLImageElement. You'll be able to decode from a Blob and upload the raw bits to a WebGL texture.

-Ken

[Alecazam]

Could you email me the contents of about:gpu from your machine off-list when the --enable-unsafe-es3-apis argument is passed to Chrome?

Done.  Seems like OpenGL 3.2+ should be enough of a desktop spec for WebGL 2.   4.1 is sort of end-of-life for GL on the Mac anyways and isn't as prevalent driver-wise (f.e. Intel).

Please file bugs against browsers, including small test cases, to get these feature gaps filled. We can try to help to point out the highest-priority issues affecting apps like yours.

Done, but we haven't seen a lot of traction (f.e. 4K limit in and shader_texture_lod on FF WebGL).   Mousewheel is still stalled out on FF, and Safari non-overridable pinch-zoom out of the app is even worse.

On the file system front, I'm just not sure how you workaround the lack of folder access, other than to hijack the security model.  Files don't even supply their directories, and Chrome defaults to a downloads folder.  At least the DropBox api supplies a list of files, so you don't have to zip.

All other File APIs seem to have fallen by the wayside as far as backing, and most only allowed access to a sandboxed directory anwyays.   Apps tend to set the last folder used for various application operations, and file formats, and even iOS/OSX has a permission model to folders where once user approved, the application can continue to reference and access those.  I haven't seen a similar effort on the web.

 

The UNPACK_COLORSPACE_CONVERSION_WEBGL pixel storage parameter is supposed to provide this control. Setting it to NONE is supposed to give you back the raw bits. Does this not work?

Also, ImageBitmap is being shipped soon in Chrome because of some nice work by the Canvas team and soon it will support https://wiki.whatwg.org/wiki/ImageBitmap_Options which will basically let you get lower-level access to the decoder, without going through an HTMLImageElement. You'll be able to decode from a Blob and upload the raw bits to a WebGL texture.

Good suggestion.   I really don't want the single-threaded and GPU dependency of the WebGL call, so ImageBitmap is more what we need.  And then wait on a universal implementation. 

[Mark Callow]

On Dec 9, 2015, at 1:27 AM, Alecazam <al...@figma.com> wrote:

Done.  Seems like OpenGL 3.2+ should be enough of a desktop spec for WebGL 2.   4.1 is sort of end-of-life for GL on the Mac anyways and isn't as prevalent driver-wise (f.e. Intel).

OpenGL ES 3.0 was based on desktop OpenGL 3.3 so using 3.2 is likely to be a problem. My late 2011 MBP’s integrated graphics supports 3.3, the discrete graphics 4.1 with OS X, 4.2 with Windows.

Regards

    -Mark

[Alecazam]

Apple used to classify it as 3.2, but they fleshed out most of 3.3 now.  Linux drivers are still stuck on Intel at 3.2/3 for many of their drivers.   The driver compiles 3.3 shaders forever, but maybe Apple caught up those extensions on El Capitan OS.  The complaint from the browser was not enough uniforms or varyings, but often WebGL shaders don't need to full count.   This Mac has integrated graphics that are 2.1 and discrete that are 3.3.   I'd just like to know what WebGL 2 requires that wouldn't run on that platform, or at least try to make it work.  I'll probably upgrade my personal Mac machine soon, but think 5 years isn't that old.