Closed t-sin closed 1 year ago
This issue is caused by that TODO. I patched to SDL2 the error does not occurs and the Lem frontend window is shown. The window is shown but redrawing has done only when the window is resized, in my environment.
@cxxxr What do you think about next actions for it? It's a problem of SDL2 so there is no quick workarounds. This needs updating libSDL2 in package manager after PR merged or patching to SDL2 by users, but these ways may weather not be easy or have done with waiting...
Thank you very much for the detailed report.
I got the impression that finding a fundamental solution for the bug in the SDL2 frontend might be difficult. Perhaps, I could avoid the problem by avoiding the use of SetRenderTarget. This might be worth trying. However, in the long term, I think it might be better to consider implementing the frontend using a different GUI toolkit.
This comment https://github.com/lem-project/lem/issues/690#issuecomment-1580248353 missed why that error occurs.
Because of that TODO code SDL2 does not check glGetError()
before glCheckFramebufferStatusEXT()
even though glGetError()
tells there is no error. The case like no GL errors, return value of glCheckFramebufferStatusEXT()
is maybe undefined, so TODO code raise that SDL error.
Progress: I made a PR to SDL https://github.com/libsdl-org/SDL/pull/7938 about that TODO.
This issue's error now does not occur by this software accelerated PR https://github.com/lem-project/lem/pull/787. And I think this problem issued here entirely solved by that SDL2 PR https://github.com/libsdl-org/SDL/pull/7938, even SDL with hardware accelerated option.
And now new problem occurred like this: SDL2 Lem launched without any conditions but with black screen. This black screen Lem is normally processing key events but simply no redrawing occurs, because we can see the string we made after manual resizing Lem's window (or minimizing and restoring).
I'm thinking about this issue:
@cxxxr What do you think about these above?
Hmmm, I don't know, so I'm just guessing. The lem-if:set-view-size is called when the window size is changed. Doesn't this behavior affect the display?
@cxxxr I found this issue is resolved by https://github.com/lem-project/lem/pull/981 with this patch:
diff --git a/frontends/sdl2/main.lisp b/frontends/sdl2/main.lisp
index 1f982687..62865ecc 100644
--- a/frontends/sdl2/main.lisp
+++ b/frontends/sdl2/main.lisp
@@ -822,7 +822,8 @@
:w window-width
:h window-height
:flags '(:shown :resizable #+darwin :allow-highdpi))
- (sdl2:with-renderer (renderer window :index -1 :flags '(#-darwin :software #+darwin :accelerated))
+ (sdl2:with-renderer (renderer window :index -1 :flags '(:accelerated))
(let* ((renderer-size (multiple-value-list (sdl2:get-renderer-output-size renderer)))
(renderer-width (first renderer-size))
(renderer-height (second renderer-size))
Off course in Linux with NVIDIA card.
So I think that the hardware acceleration can be used in Linux.
Thank you. Also, there must have been a problem with the radeon, so we need to check that out.
Environment
Steps
ros install lem-project/lem
lem -f sdl2
As is
Black painted SDL2 frontend window appears and it crushes with these logs:
crush logs with `(lem:lem "--debug" "--log-filename" "lem.log")`
```This issue does not occur in my laptop (Intel Graphics driver).
To be
SDL2 window appears rendered with Lem editor screen.
My debugging
I saw this error in that log:
so I think this is caused by SDL2 or graphc driver layer. I found some
glFramebufferTexture2DEXT()
related articles like these:but these are not reasons of this issue.
BTW I found codes to raise this error in SDL2 codes:
I think this issue may be caused by illegal pixel format on this environment but I cannot know how different each texture formats between renderer and
(lem-sdl2:create-texture)
.