Vulkan support

[dalerank]

Hello @wjakob I add vulkan render backend for nanogui here https://github.com/dalerank/nanogui/commit/53f59f23c02e3e920380d5b814cdf52821849fb6 commit based on https://github.com/danilw/nanovg

[cesss]

Do you consider it a good backend? I'm asking because I remember I did read in this or in other fork that NanoVG doesn't have a design that matches the concepts used in Vulkan, thus the Vulkan backend was not efficient, and the author didn't recommend to use it. Now, I don't remember if it was this fork or another one.

[dalerank]

@cesss you can try how it work here https://github.com/dalerank/nanogui

[cesss]

Thanks a lot!!

[cesss]

BTW, is the OpenGL 2.x backend for NanoVG in working state? (yes, I'm on Vulkan and OpenGL 4.x, but a fallback for older machines would be nice).

[dalerank]

@cesss possible yes, but im not tested

[cesss]

Thanks a lot, dalerank. You seem to be progressing a lot in your fork! BTW, is there any reason why you are forking from this version and not from the Mitsuba one? (I ask because I'm also wondering if the Mitsuba version is the one to follow or not)

[dalerank]

@cesss it have some ideas which cant be ported :( forexample I avoid RTTI and used custom runtime info, because much projects disable it for speed, but mitsuba using it everywhere, I'll check changes in upsteam and backport are soon

[wjakob]

@dalerank : That's very unfortunate -- my group plans to maintain the mitsuba-renderer branch going forward, this one here will receive at most basic maintenance. It's actually not clear to me what you mean by RTTI-related differences. It should be exactly the same as here. The original impetus was a switch to a different vector math library, but since then I have integrated many improvements that are not found in wjakob/nanogui. (But again, I don't see how RTTI is any different.)

[dalerank]

@wjakob I saw, thanks a lot for your work, it really great lib, but look around in really projects where it can be used, bgfx forexample, or UE4, rtti disabled, because it very expensive for speed :( also I fully avoid eigen and add base classes for vec2/color, it works. Also some time ago I add software render backend here https://github.com/dalerank/nanogui-sdl, but it much-much difference from nanogui ))) dont know how it can make integrate here

[dalerank]

and exceptions it also very expensive in really projects, most of projects disabled exceptions by default

[dalerank]

@cesss Yet once, my goals not a new widgets UI library, I want to create Figma open source alternative (www.figma.com)

[cesss]

@dalerank Ooh!! So you are the author of the SDL2 nanogui port!! :-) I prefer SDL2 over GLFW, because I really want complete multiplatform code, and GLFW doesn't have mobile (iOS/Android) backends yet. But, rather than using a SDL2 port, I'd rather prefer to encapsulate the windowing lib as a window-backend or something, so that nanogui doesn't depend on GLFW nor on SDL2, nor in any other windowing lib, just plug the one you prefer.

[dalerank]

sdl2 port too slow, and not used gpu (because it not really on SDL2, it hides all gpu workaroud) @wjakob create amazing lib, but using all features from nanovg gpu depends

[cesss]

Oh, so your SDL2 port doesn't use OpenGL windows? How strange! It's really easy to create OpenGL views in SDL2! Anyway, it looks like I'll need to develop my own fork for encapsulating the windowing API in a transparent way (so that you can choose from SDL2, GLFW, or whatever windowing API of your choice). I'll try to adopt your Vulkan efforts, because I want to be OpenGL+Vulkan (not interested in Metal --yes, I'm a long-term Mac user, but precisely because of that, I'm skipping Metal, I'm going MoltenVK instead).

[dalerank]

@cesss look at early coomits, where im used sdl2+opengl, but later I add software render that avoid another depends only sdl2