Error: "extension to create ES context with wgl is not present"

[Unknown78]

Background

OS: Windows 11 v10.0.22631.2715 64-bit
CPU: Intel i3-2310M
GPU: Integrated Intel HD Graphics 3000

App: Release 0.7.7

---

Steps to Reproduce

Run oculante.exe

Expected Behaviour

It opens as usual.

Actual Behaviour

It closes itself.

Logs

set RUST_LOG=debug && oculante > oculante.log
Only stdout will output nothing.

It turns out that combined stderr, stdout and set RUST_LOG=debug is too much.
set RUST_LOG=debug && oculante > oculante.log 2>&1

Just stderr is suffice.
oculante 2> oculante.log

Error: "extension to create ES context with wgl is not present"

Found something that may related:
https://rustrepo.com/repo/tomaka-glutin
rust-windowing/glutin#1550
rust-windowing/glutin#1553

[woelper]

It seems your graphics card supports OpenGL 3.0, where Notan requires OpenGL 3.3.

[Unknown78]

The driver may be the issue that prevents me from having OpenGL 3.3
A reddit post claim to have OpenGL 3.3 on Linux.

The graphics driver that came from Windows Update on Windows 11 only supports OpenGL 1.1

With an unofficial driver and its tutorial, I have OpenGL 3.1 now.
The developer of it claims in this post that the hardware supports OpenGL 3.3 but Intel just don't deploy the driver of it.

---

@woelper I couldn't find any Image viewer that's updated and written purely on Rust except this.
Could you please implement fallback mechanism by using different engine or something like that?

[woelper]

Thanks for sharing!

I've thought about this, but there is significant work attached to this for relatively low gain. I've actually even made some progress to offload some of the operations into the UI, which can be used on top of other libraries, even software-rendered ones. But in short, a fallback would mean:

• I am currently using a lot of engine features and data types, like Vec2 for example. If I want to transition / use a fallback, I would need to use a different data type and convert between them. This is not only more code, but also possibly a performance issue.
• The engine is doing a lot of window management (set always on top, full screen, setting an icon, window title...) - all that would need to be done for several frameworks or even manually.
• The engine does input handling as well, so for example mouse movement, scrolling, keyboard shortcuts... especially the shortcuts were a lot of work. If a different framework/engine would be used, these things would need to be redone.