SDL slowness while scrolling in Firefox on X11

Scrolling in Firefox in GNOME/Compiz (with at least the nouveau driver) makes SDL_Flip() and SDL_RenderPresent() (SDL2) extremely slow for me, to the point of only being able to do ~30 FPS with everything removed but those calls. Chromium doesn't cause nearly the same slowdown. Might be related to the way Firefox draws the screen, if it needs to DMA a lot of data or causes some lock to be held for a long time, but that's just speculation.

Anyone else seeing the same thing? Might need to drop SDL_Flip() flip calls or do the emulation in a separate thread that signals the rendering thread to get around it I guess. Currently it causes bad sound stuttering (especially with SDL2) as sample generation is done in the same thread that SDL_Flip()s (and yeah, that's arguably poor practice anyway).

Using software rendering doesn't help btw, so I'm guessing it's hitting a bottleneck in the 3D-accelerated desktop.

Firefox > Preferences > Preferences > Advanced > General > Browsing
Turn OFF smooth scrolling, as I did several Firefox versions ago, and see if that fixes anything. I couldn't even find a smooth scrolling setting in Chromium, so I have a feeling that might be the reason for the difference.

Also, see what happens if you try a non-compositing windowmanager.

Might've made it marginally better, but it's still worse than Chromium.

Another thing I just noticed really slows it down is bringing up the translucent Ubuntu menu in Unity (regardless of whether it overlaps the window). As I want my emu to work well on common setups without tweaking, I'll probably go with a separate rendering thread. I could have it drop the new frame if the old one hasn't finished uploading.



Would be an interesting experiment, as long as I don't mess up my install somehow.

Yeah, that's definitely the fault of the compositor, albeit exacerbated by the nouveau driver. Not that telling people to switch to a less awful desktop environment is a serious option...

Split off emulation and SDL stuff into separate threads, and now the audio runs fine even though video framedrops like crazy with the Ubuntu menu open. Another thing it hates is when you place the window so it overlaps the border between two monitors. Robust stuff...

I know, right? I can't tell you how many times I need to play SMB with the window half way between two monitors with the menu screen overlay open. It's so inconvenient and I'm considering moving to something else until SDL2 gets its act together.

It happens with SDL1 too, and it's more about general robustness and not having sound crap out whenever a menu is opened or whatever.

I really would have thought that proper xrandr 1.2+ support would have fixed cross-head problems: internally both CRTCs should be set up to read from the same linear framebuffer without any memory discontinuities that would cause performance problems...

I suppose SDL could be being Too Smart and ignoring the xrandr data for just the xinerama data and splitting the texture into two? I wonder if you made an xinerama-ignorant build of SDL whether it would improve performance.

Played around with the SDL_VIDEO_X11_XINERAMA and SDL_VIDEO_X11_XRANDR environment variables, but no setting seems to eliminate the slowdown. Could be a problem below the SDL level.

The SDL_VIDEO_X11_XRANDR documentation says "by default SDL will not use XRandR because of window manager issues" by the way, but running with SDL_VIDEO_X11_XRANDR=1 makes no difference.