Question: MSVC Undefined GL Identifiers

[mfisher31]

I'm getting alot of undefined identifiers on windows in LVTK. As of now, the setup only uses <pugl/gl.h> for GL-including purposes. the nanovc*.c files below were modded to use pugl/gl.h as well.

The first thing I did was build pugl by itself and run the examples. obviously this isn't a pugl problem.

Do you remember seeing things like this in the past:

libnanovg.a.p/nanovg_gl.c.obj "/c" ../src/nanovg/nanovg_gl.c
../src/nanovg/nanovg_gl.c(394): error C2065: 'GL_VERTEX_SHADER': undeclared identifier
../src/nanovg/nanovg_gl.c(395): error C2065: 'GL_FRAGMENT_SHADER': undeclared identifier
../src/nanovg/nanovg_gl.c(402): error C2065: 'GL_COMPILE_STATUS': undeclared identifier
../src/nanovg/nanovg_gl.c(409): error C2065: 'GL_COMPILE_STATUS': undeclared identifier
../src/nanovg/nanovg_gl.c(422): error C2065: 'GL_LINK_STATUS': undeclared identifier
../src/nanovg/nanovg_gl.c(710): error C2065: 'GL_GENERATE_MIPMAP': undeclared identifier
../src/nanovg/nanovg_gl.c(748): error C2065: 'GL_CLAMP_TO_EDGE': undeclared identifier
../src/nanovg/nanovg_gl.c(753): error C2065: 'GL_CLAMP_TO_EDGE': undeclared identifier
../src/nanovg/nanovg_gl.c(978): error C2065: 'GL_INCR_WRAP': undeclared identifier
../src/nanovg/nanovg_gl.c(979): error C2065: 'GL_DECR_WRAP': undeclared identifier
../src/nanovg/nanovg_gl.c(1151): error C2065: 'GL_TEXTURE0': undeclared identifier
../src/nanovg/nanovg_gl.c(1175): error C2065: 'GL_ARRAY_BUFFER': undeclared identifier
../src/nanovg/nanovg_gl.c(1176): error C2065: 'GL_ARRAY_BUFFER': undeclared identifier
../src/nanovg/nanovg_gl.c(1176): error C2065: 'GL_STREAM_DRAW': undeclared identifier
../src/nanovg/nanovg_gl.c(1209): error C2065: 'GL_ARRAY_BUFFER': undeclared identifier
ninja: build stopped: subcommand failed.

If so, is there some flag I'm missing for windows + gl that you know of I can try to fix this? Wouldn't mind knocking it out while the day job has me doing alot of windows stuff.

LVTK doesn't check for GL whatsoever. It just uses pugl-gl's pkg-config or subproject.

[drobilla]

Don't think I've seen that, but these are relatively new symbols as far as GL goes. That usually comes up at runtime though (because you need to jump through quite a few hoops on Windows to get a context with modern GL features).

What version of windows / drivers / etc?

[drobilla]

On second thought you probably need glad or a similar loader for this stuff. I'm not sure you can expect them to be available in the Windows headers, and even if they were, it wouldn't work because they need to be dynamically loaded anyway. See e.g. pugl_shader_demo.

[mfisher31]

Setup pretty good over here :) I was hoping glad wouldn't be needed. no biggie.

Also hooked in to an HDPI monitor. System is dual boot windows 10 and ubuntu 20. I'm expecting there to be hurdles to overcome in multiple monitor setups. i.e. the mixing of HDPI and non-HDPI displays.

[drobilla]

I imagine there definitely will be when moving things between screens.

I added some DPI things recently and I knew it was sketchy, but, ahem, someone convinced me that was fine so I punted on it for now. I'm pretty sure screen DPI and anything similar needs to be added to configure events to do this at all correctly, but haven't worked on that yet. It's a bit annoying since you need to know which screen you're going to display on, which means the view needs to be realized, but people want to set things up and know the DPI before then. I doubt that's really possible without adding a whole monitor API, but we'll see.

That aside, for programs it should magically just work fine. For plugins, the host is responsible for calling SetProcessDPIAware or doing the equivalent thing in the application manifest or whatever.

[drobilla]

I was hoping glad wouldn't be needed

Not really a thing at all these days, unfortunately, unless you're writing prehistoric fixed function pipeline code, which is terrible.

Personally I just gave up and am all-in on Vulkan.

[mfisher31]

Will see what this vulkan thing is all about: never heard of it until a few weeks ago. Might be a good idea and bite the bullet early.
NanoVG + GL seems to work with glad though on windows. compiles at least.

[drobilla]

If you're working through an abstraction layer like nanovg and it has support, worth checking out.

Using Vulkan directly/manually is very brutal though. It's technically a million times better, but the cost in explicit verbosity is very high.

[mfisher31]

https://github.com/jpbruyere/vkvg gonna try that one.

[mfisher31]

I added some DPI things recently and I knew it was sketchy, but, ahem, someone convinced me that was fine so I punted on it for now. I'm pretty sure screen DPI and anything similar needs to be added to configure events to do this at all correctly, but haven't worked on that yet.

talking about puglGetScaleFactor? This is all that's needed for a GUI to convert back and forth between logical and physical pixels.... assuming that Pugl never tries to do internal coordinate scaling.... personally I don't think it should.

[mfisher31]

View converts all incoming pugl events to logical pixels before passing along to widgets. https://github.com/lvtk/lvtk/blob/v3/hidpi/src/ui/view.cpp

LowLevel context uses same scaling as the View. https://github.com/lvtk/lvtk/blob/v3/hidpi/src/ui/nanovg.cpp

The user facing Surface and Graphics API is all in logical coordinate space.

[mfisher31]

Oh and by the way. Apparently mix-matched dual monitors "just works". At least it does over my way.

[drobilla]

Even with different DPIs? Hm. Well, that's nice, if surprising. What pugl is doing now definitely has problems, I think (interface is flawed, I merged it anyway to get on with things), but maybe it's Good Enough for 90% of cases.

I do have laptops and an external display with wildly different pixel densities, so I'll get around to trying one of these days, but I don't actually use multiple monitors myself so it's a bit of a chore to bother.

[mfisher31]

Yep. Seemed to just work with a 4k + standard 1080p. With my setup there were differences in behavior between linux and windows. Linux needs "Fractional Scaling" enabled, whereas windows "just worked".

A Pugl Window Split between two monitors On Linux a split window looked as you expect, same perceived magnification. On windows, one-or-the-other scale factors would be applied on both monitors. e.g. One side looks normal while the other is either zoomed in, or squished.

I normally don't use multi monitors either, but was motivated in my last binge of LVTK to try the mix matched DPI scenario. Knowing the scale factor via puglGetScaleFactor is IMHO essential. With this information alone, toolkit devs can do the logical <=> physical pixel conversions without toolkit end-users having to even think about it.

--

[drobilla]

On windows, one-or-the-other scale factors would be applied on both monitors. e.g. One side looks normal while the other is either zoomed in, or squished.

Yeah, this is what I expect (like, in current reality, not ideally of course). I'm on the fence as to whether an accessor like this should even exist at all (ideally not, it encourages exactly this kind of brokenness), but it's clearly not sufficient. All things related to "configuration" need to be conveyed in configure events for things to work properly.

[falkTX]

related to this, on macOS the experience is different. on a setup with 2 different scale factor displays, unless the application supports something custom (dont know what that API is) only half the window appears when it is placed in between the screens. when most of the window is moved to another screen, that is the screen where it appears visible on, with the other part then becoming hidden.

[drobilla]

Hm. Odd since MacOS is (I think?) always indirectly rendered anyway.

Although windows not fully displaying when simultaneously on two different displays with different pixel densities isn't the end of the world (it's not like you could really use the UI like this anyway), but hopefully that's an easy fix because it'll look janky when dragging them at least.