1. 22 Jul, 2021 29 commits
    • Benjamin Otte's avatar
      gdk: Add a private struct to GdkDisplay · 581e01b2
      Benjamin Otte authored
      ... and move some members from the GdkDisplay struct.
      
      We've always wanted to add one to isolate the display from the backends
      a bit more, but so far it's never happened.
      
      Now that I'm about to add more data to GdkDisplay, it's a good excuse to
      start.
      581e01b2
    • Benjamin Otte's avatar
      x11: Redo choice between EGL and GLX · 5a3b4de1
      Benjamin Otte authored
      We try EGL first, but are very picky about what we accept.
      If that fails, we try to go with GLX instead.
      And if that also fails, we try EGL again, but this time accept anything.
      
      The idea here is that EGL is the preferred method going forward, but GLX is
      the tried and tested method that we know works. So if we detect issues with
      EGL, we want to avoid using it in favor of GLX.
      
      Also add a GDK_DEBUG=gl-egl option to force EGL at all costs and not try
      GLX.
      5a3b4de1
    • Benjamin Otte's avatar
      x11: Properly record the error when initializing GL · 74288ece
      Benjamin Otte authored
      That way, we can give a useful error message when things break down for
      users.
      
      These error messages could still be improved in places (like looking at
      the actual EGL error codes), but that seemed overkill.
      74288ece
    • Benjamin Otte's avatar
      x11: Do not call glXQueryExtension() · 37ba0571
      Benjamin Otte authored
      epoxy does that already.
      37ba0571
    • Benjamin Otte's avatar
      x11: Get Visual from EGL directly · 6d5ba959
      Benjamin Otte authored
      Query the EGL_VISUAL_ID from the egl Config and select a config with the
      matching Visual.
      
      This is currently broken on Mesa because it does not expose any RGBA
      X Visuals in any EGL config, so we always end up with opaque Windows.
      
      https://gitlab.freedesktop.org/mesa/mesa/-/issues/149
      6d5ba959
    • Benjamin Otte's avatar
      x11: Store the GLX drawable in the surface · 215f7928
      Benjamin Otte authored
      Also, stop using a dummy window for unattached GL contexts and instead
      use the display's leader surface.
      
      Again, this mirrors EGL.
      215f7928
    • Benjamin Otte's avatar
      x11: Use single GLX fbconfig and store it in the display · 1c55b328
      Benjamin Otte authored
      This mirrors the code for the EGL config.
      1c55b328
    • Benjamin Otte's avatar
      x11: Remove glx version check · 82eb947f
      Benjamin Otte authored
      We only work with GLX >= 1.3 anyway, so don't explicitly check for it
      and pretend to do something else that doesn't work otherwise.
      82eb947f
    • Benjamin Otte's avatar
      x11: Remove unused struct member · 485dae9f
      Benjamin Otte authored
      We don't care if the GL context is direct at all.
      485dae9f
    • Benjamin Otte's avatar
      Revert "x11: Always fall back to GLX on NVIDIA" · eb342331
      Benjamin Otte authored
      This reverts commit c35a6725.
      
      This approach doesn't work because if NVIDIA doesn't work for EGL, the
      EGL implementation won't be provided by NVIDIA, so checking the vendor
      doesn't work.
      eb342331
    • Benjamin Otte's avatar
      x11: Remove the dummy surface · 04c2093d
      Benjamin Otte authored
      Instead, use the display's "leader surface" when no surface is required,
      because we have it lying around.
      
      Really, we want to use EGL_NO_SURFACE, but if that's not supported...
      04c2093d
    • Benjamin Otte's avatar
      x11: Remove GdkVisual · ccd5992a
      Benjamin Otte authored
      It's not used anymore.
      ccd5992a
    • Benjamin Otte's avatar
      x11: Rework Visual selection · ca8d9fbe
      Benjamin Otte authored
      Instead of going via GdkVisual, doing a preselection and letting the GL
      initialization improve it, let the GL initialization pick an X Visual
      directly using X Visual code directly.
      
      The code should select the same visuals as before as it tries to apply
      the same logic, but it's a rewrite, so I expect I messed something up.
      ca8d9fbe
    • Benjamin Otte's avatar
      glx: Remove Visual cache · 62bac44a
      Benjamin Otte authored
      1. We're using EGL most of the time anyway, so if we wanted to cache
         things, we'd need to port it there.
      2. Our GL handling is massively configurable, so determining when to use
         the cache and when not is a challenge.
      3. It makes startup nondeterministic and depend on whether a GTK4 app
         has previously been started on this display and nobody thinks about
         that when debugging.
      4. The only benefit of the caching is delaying GL initialization - which
         made sense in GTK3 where almost no app used GL but doesn't make sense
         in GTK4 where almost every app uses GL.
      
      So unless I find a big benefit to reintroducing it, this cache will be
      gone for good.
      62bac44a
    • Benjamin Otte's avatar
      x11: Move GL init code into the GL context · 0ddd0611
      Benjamin Otte authored
      No functional changes, just shuffling code.
      0ddd0611
    • Benjamin Otte's avatar
      x11: Store the EGL surface in the GdkSurfaceX11 · b1fbc2ef
      Benjamin Otte authored
      Avoids having to use private data, though the benefit is somewhat
      limited as we still have to put the destructor in the egl code and can't
      just put it in gdk_surface_x11_finalize().
      b1fbc2ef
    • Benjamin Otte's avatar
      x11: Store the EGL config in the display · c787fe7e
      Benjamin Otte authored
      We only have one config, because we use the same Visual everywhere.
      Store this config in the GdkDisplayX11 struct for easy access.
      
      Also do this on initialize, because if creating the config fails, we
      want to switch to GLX instead of failing to do GL at all.
      
      This also simplifies a lot of code as we can share Visual, Colormap, etc
      across surfaces.
      c787fe7e
    • Benjamin Otte's avatar
      x11: Move the EGL display into the private struct · bdb49720
      Benjamin Otte authored
      There's no need to use g_object_set_data() for it.
      
      We can also stop caching it elsewhere because we know the display has
      it.
      
      And finally, we can remove the display->have_egl boolean and use
      display->egl_display != NULL instead. We initialize the display at
      startup, so that variable is the perfect indicator.
      bdb49720
    • Benjamin Otte's avatar
      x11: Pass the display, not the screen · 1d448a2b
      Benjamin Otte authored
      Screens are on their way out.
      1d448a2b
    • Benjamin Otte's avatar
      x11: Simplify code · c5df0819
      Benjamin Otte authored
      These variables were a lot more important in GTK3, but now we just want
      to pass them through to X.
      c5df0819
    • Benjamin Otte's avatar
      x11: Move function call · 8a2f3e1f
      Benjamin Otte authored
      The GLX visual selection is GLX specific, so it can be handled by the GLX
      code.
      
      There should be no reordering here, the call was just moved.
      8a2f3e1f
    • Benjamin Otte's avatar
      glx: Don't initialize GLX multiple times. · 8dfc627e
      Benjamin Otte authored
      Either it is initialized or it isn't.
      8dfc627e
    • Benjamin Otte's avatar
      x11: Initialize GL at startup · 0fce3007
      Benjamin Otte authored
      We need to initialize GL to select the Visual we are going to use for
      all our Windows.
      
      As the Visual needs to be known before we know if we are even gonna use
      GL later, we can't avoid initializing it.
      
      Note that this previously happened, too. It was just hidden behind the
      GdkScreen initialization.
      0fce3007
    • Benjamin Otte's avatar
      x11: Don't share cached GLX visuals with GTK3 · 8bfe82f6
      Benjamin Otte authored
      We don't want to bind ourselves to GTK3 - both because we don't want to
      accidentally cause bugs in a different codebase and because we want to
      deviate from it.
      
      While doing so, also store visuals as visuals and not as integers.
      And only store one Visual because GTK4 only uses one visual.
      
      And then remove the code that is leftover for dealing with the
      compatibility Visual for GTK3.
      
      PS: I'm kinda proud of my STRINGIFY_WITHOUT_BRACKETS hack.
      8bfe82f6
    • Benjamin Otte's avatar
      x11: Reorder code · 7d32ec51
      Benjamin Otte authored
      Initialize the GL visuals from gdkdisplay.c so the call into the GL
      stack isn't hidden in gdkvisual.c
      
      This is relevant for further commits.
      7d32ec51
    • Benjamin Otte's avatar
      x11: Stop reordering visuals · 5784f8c2
      Benjamin Otte authored
      The old code was ordering visuals by depth, but considering that these
      days we either use the default visual or a 32bit RGBA visual, that
      reordering does not have an effect anymore.
      
      In theory, the only effect is that the GLX Visual selection might select
      a different replacement Visual when it checks for improved GL Visuals, but
      even there I can't come up with a case where that matters, because
      again, the visuals are only reordered by depth and we want to keep the
      depth.
      
      In any case, make this a separate commit so bisecting can find this
      problem if it ever shows up.
      5784f8c2
    • Benjamin Otte's avatar
      x11: Remove unused function · 74e01dde
      Benjamin Otte authored
      Now that we can't create extra GdkX11Screens anymore, this also means
      that there is exactly 1 GdkX11Screen per GdkX11Display.
      74e01dde
    • Benjamin Otte's avatar
      x11: Move code where it belongs · 13475731
      Benjamin Otte authored
      Instead of the display telling the screen to tell the visuals to tell
      the display to initialize itself, just init the display directly.
      
      What a concept.
      13475731
    • Benjamin Otte's avatar
      build: Build demos before tools · f2b41e70
      Benjamin Otte authored
      That's a sneaky trick so my edit/compile/test cycle goes faster:
      I usually use demos for testing so the tools don't have to be linked for
      me to start testing.
      f2b41e70
  2. 21 Jul, 2021 3 commits
  3. 20 Jul, 2021 8 commits