We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3984

Summary: SDL_WINDOW_BORDERLESS difference between SDL2 2.0.6 and 2.0.7 on Windows
Product: SDL Reporter: Corjan <corjanhamer>
Component: renderAssignee: Sam Lantinga <slouken>
Status: RESOLVED ABANDONED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: sezeroz
Version: 2.0.7   
Hardware: x86   
OS: Windows 10   

Description Corjan 2017-11-28 10:12:36 UTC
Hi,


I just updated SDL2 from 2.0.6 to 2.0.7, and I noticed a big change in how the SDL_WINDOW_BORDERLESS flag behaves. I’m running windows 10.

In 2.0.7 it seems that the top bar is hidden, but everything still works as it it is still there. Hovering over the hidden top bar will also give mouse motion events, the first actual renderered pixel starts around y=20. You can even drag the window by grabbing where the top bar normally would be.

There is also no way to get the window all the way to the top of the monitor, since it always requires space for the hidden top bar.


Thanks for your reply,

Corjan
Comment 1 Sam Lantinga 2017-11-28 19:30:20 UTC
I'm looking at this now, thanks!
Comment 2 Sam Lantinga 2017-11-29 02:45:37 UTC
Can you check to see if this fixes it for you?
https://hg.libsdl.org/SDL/rev/93edd752e966

Thanks!
Comment 3 Corjan 2017-11-29 09:16:12 UTC
Hi,


First, thanks for your quick response!
Unfortunately, this didn't help.

Are you able to reproduce the problem?
From what we have gathered, it doesn't happen on all systems. To complicate things further :)

To illustrate the problem, I have made a small video:
https://www.dropbox.com/s/qhr015vwdtoj15v/2017-11-29%2010-13-59.mp4?dl=0


Please let me know if I can assist you further in any way,

Corjan
Comment 4 Sam Lantinga 2017-11-29 17:48:13 UTC
No, I'm unable to reproduce the problem. I'm running Windows 10 here as well. Are you running the Creator's Update?

Can you reproduce it by running the testsprite2 test program with the --noframe command line option?
Comment 5 Corjan 2017-12-04 10:49:31 UTC
Hi,


Sorry for the slow response.

I tried the sprite test, that one works fine. My windows version has the creator's update.

In my code, I also use the SDL_SetWindowHitTest, SDL_SetWindowPosition and SDL_SetWindowSize runtime. It might have something to do with that.


I'll try to narrow it down if I can. I'll get back to you,

Corjan
Comment 6 Corjan 2017-12-04 11:05:02 UTC
Tried removing all three functions, but that didn't solve it unfortunately.

Maybe I'm doing something wrong with the overall structure of my code.
Our application can create multiple SDL windows.

For each window, I create a separate thread in which I do this:

INIT:
  SDL_CreateWindow (SDL_WINDOW_OPENGL | SDL_WINDOW_BORDERLESS)
  SDL_SetWindowIcon
  SDL_GL_CreateContext
  <init GLEW>

FRAME:
  SDL_GL_MakeCurrent
  SDL_SetWindowHitTest
  SDL_PollEvent
  SDL_SetWindowPosition
  SDL_SetWindowSize
  SDL_GL_SwapWindow


I hope this helps...

Corjan
Comment 7 Corjan 2017-12-04 11:06:57 UTC
Also something useless I noticed is that the SDL window in SDL 2.0.7 comes up 'smoothly' with the while Windows Aero thingy.

In the previous 2.0.6 it wouldn't do this animation.


Corjan
Comment 8 Ryan C. Gordon 2018-08-06 21:20:24 UTC
Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.