I'm no expert in GL, I'm going by what I've heard and read in my spare time. Feel free to correct me when I'm wrong. =D
I don't mean you're wrong. I mean devs probably don't think about cursor replacing code as much as we do. They just used code which worked for them. PS: I love these smiles... ^_^
Why should they bother to use multiple "real" windows for that? They might as well render them all in one single "real" window? EDIT: And even if that borderless window concept somehow should end up making sense you could easily detect this situation and render the cursor on all windows in this kind of edge case.
It's just an idea. But splitting different viewpoints to different windows/processes might give game more scalability while it's will be more stable. It's also might give better performance because operation system window managers are designed to effective manage windows. Yes you can, but it's might create more problems than current solution. I doubt Uber think about possible problems while they done version of cursor support. You just never know what problems you met when you create some brand-new engine.
Isnt this a problem with the compositing window manager and maybe not so much with the driver?. I'v found that: Gnome3 + mutter = mouse cursor bug LXDE + xcompmg = no mouse cursor bug
There is no bugs (except very slow flickering, e.g no blackbox, no stopped refreshing while OpenGL used for KWin) on open source drivers. On proprietary drivers flickering fixed used tear free, so I think it's a bit different problems. PA actually even work with LLVMpipe. PS: Please report issues with screenshots and video (recordmydesktop good tool) on AMD forums.
Do they? I have used Linux with Nvidia drivers for 15 years, and the only problem I have is with PA. I won't try to report a bug with Nvidia unless I can prove there actually is one. I can prove there is a bug with PA, and since others have found the same thing, there must be something to it. Why else would other games, even in a window and with a custom cursor not have these same issues if it was a driver bug? My guess is this first attempt by Uber to replace the Linux cursor for PA was the wrong method. I hope they can find a better method once they decide to try.
Interesting fact: there is no flickering on LLVMpipe, e.g cursor working exactly like on Windows. PS: Just done other testing on Intel HD 3000, completely no flickering with TearFree and SwapbuffersWait enabled. No mater if Kwin use OpenGL or XRender.
Which cursor bug is this about exactly? I am not 100% clued up on the Linux specific bugs. The first post didn't state which bug it was. Just found the link to the bug. I get a different one, while shift building, letting go of shift does not remove the building from my cursor , so I am stuck with the last building i selected wanting to be placed again.
*IF* this is a driver issue, and this helps hone in onto it, it is related to Composite SINCE 1) I do not get this issue with OPENBOX (even with composite enabled in xorg.conf and/or xcompmgr running) 2) I get this with CINNAMON no if's but's or maybe's
@ssx has a good idea here, and I'd like to see if uber (@garat @UberGaf @UberWilliam) would be willing to take it one more step. I'd like to get a barebones app running and open-sourced that mimics what PA is doing. I'm guessing the main window is an opengl context and the overlays are all chromium's embedded framework (per @ssx) That way, we can all compile and run on our machines, make tweaks as necessary, submit pull requests for things that work on our machine, etc. Anyone think this idea could get traction?
I don't see it as good idea because none of people who posted here spend a minute to register on AMD/Nvidia forums and just try to ask about their real problem with cursor tearing. Tweaks, pull requests? LOL. I seriously doubt Uber need to waste any resources on anything like that.
Some of us already have an account Equally some of can no longer reproduce due to a gnome purge in light of systemd being forced on them I also attempted to make a desktop recording a few months ago when I first spotted it using ffmpeg and the x11grab pipe, thats when I noticed it wasn't appearing in that bid (now on yt) so either the flicker was being aliased out by the forced 60fps at ffmpeg layer or the flickering is being induced at a layer above x11 (and hence ffpmpeg wouldn't be able to grab it)
The cursor tearing is really a second priority for me at the moment. Yes, it's a problem when using my Intel card, but I'd like to see this running on my nvidia card before I start trying to re-configure my system to get the cursor working 100% properly. No idea if the devs are working on the optimus issue or not - I don't know if they have any optimus machines in-house. Thus, it seems like a way of doing some practical tests and finding solutions to the variety of configurations out here in linux land.
the dev's shouldn't work on per-card solutions BAD precedent. They should work on OGL compliance and X11 compliance as they are REMEMBER this is a steep learning curve for uber, right now they have alot of content to add and the linux client is tracking the main build quite nicely. There are other gfx issues as well (I had some nasty metal planet texture issues last night) but the client builds, runs and is compatible. The best we can do as ALPHA supporters is to provide as much info as possible to Uber to help them narrow down this issue OR for the driver manufacturers to fix their drivers ... but with it effecting Intel,AMD,Nvidia cards this would point more to a Uber issue
Well, like I said, I'm not targeting a specific card. I'm targeting a general category of technology, of which I happen to be a user. Same goes with the rest of y'all. If they have uncertainties about how to approach a given technology, then it's useful information to know how specific, controlled configurations work across technology sets. The more data, the better you can adjust. Basically, I'm positing that they form the experiments, they're in-house test-beds are the control, and our machines (and the tweaks we make) are the experimental results. Integrate as it makes sense - do more fine grained experiments as it makes sense - and win.
You can't fix problems of Nvidia owners by just being compliant with OGL and X11 because Nvidia never supported Optimus on Linux and it's real reason of these problems.
Coherent renders web pages to bitmaps and it is up to us to get those bitmaps onto the screen somehow. The main page we just upload to an OpenGL texture and draw as a fullscreen quad. For the cursor we use the standard XCursor library with calls like XcursorImageLoadCursor. We could hide the system cursor and compose the cursor image ourselves but that has a couple of downsides, primarily that it adds more lag between when the mouse moves and when the cursor moves. That code is so simple I don't see how there is room for us to do anything wrong. Or at least nothing that could explain the failures I'm seeing. As for why things fail for us and not for other games, my best guess is that it is related to how we create the OpenGL context and how that ends up interacting with the desktop composer. If it turns out that we have to manage the cursor ourselves instead of using the Xcursor library, then we will. But I hope we don't have to go down that route because that would be a lot of platform specific work just to reimplement the functionality that Xcursor is supposed to provide.
