Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. QML and Qt Quick
  4. Native Qt QML Fullscreen application
Forum Updated to NodeBB v4.3 + New Features

Native Qt QML Fullscreen application

Scheduled Pinned Locked Moved Unsolved QML and Qt Quick
5 Posts 3 Posters 1.6k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Z Offline
    Z Offline
    Zack
    wrote on last edited by
    #1

    I would like to now, whether it is possible to create a native fullscreen application with QML?
    I know there is the "fake fullscreen" approach, with maximizing the window to screen coordinates.
    However, this is not real native fullscreen.

    With native I mean, that you can set a custom resolution to the monitor and then QML renders into it.
    I asking because there is a performance difference, between rendering in native fullscreen widget or fake fullscreen widgets.
    See here for details:
    https://www.reddit.com/r/pcgaming/comments/5gz5wc/what_is_the_difference_between_fullscreen_and/

    J.HilkJ 1 Reply Last reply
    0
    • Z Zack

      I would like to now, whether it is possible to create a native fullscreen application with QML?
      I know there is the "fake fullscreen" approach, with maximizing the window to screen coordinates.
      However, this is not real native fullscreen.

      With native I mean, that you can set a custom resolution to the monitor and then QML renders into it.
      I asking because there is a performance difference, between rendering in native fullscreen widget or fake fullscreen widgets.
      See here for details:
      https://www.reddit.com/r/pcgaming/comments/5gz5wc/what_is_the_difference_between_fullscreen_and/

      J.HilkJ Offline
      J.HilkJ Offline
      J.Hilk
      Moderators
      wrote on last edited by
      #2

      @Zack
      I don't think its possible to change the OS screen resolution with an qt-api, Youll have to call plattform specific code.

      For Windows, take a look here:
      https://msdn.microsoft.com/en-us/library/dd183411(v=vs.85).aspx


      Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


      Q: What's that?
      A: It's blue light.
      Q: What does it do?
      A: It turns blue.

      1 Reply Last reply
      1
      • timdayT Offline
        timdayT Offline
        timday
        wrote on last edited by
        #3

        Curious why you'd want to do this these days. Back in the days when CRT monitors were the norm it was common enough (together with ghastly flickering and curious clicking noises from the monitor as the mode was changed)... but now in my experience most LCD displays look absolutely terrible if you drive them at anything other than their native resolution.

        If for performance reasons you want to render a (say) 960x540 window instead of a display resolution 1920x1080, better to render at that resolution then scale up at the final step using a shader effect maybe (at that point you have a chance to apply an adaptive sharpening filter to try and hide the fact you're rendering at lower resolution).

        1 Reply Last reply
        0
        • Z Offline
          Z Offline
          Zack
          wrote on last edited by Zack
          #4

          I need to render some output from a camera in fullscreen as fast as possible.
          My internal tests has shown that when rendering with native directX and its done in fullscreen I get a latency of 65ms, when using windowed mode I get a latency of 75ms.
          Using QML I am arround 80ms, so I have asked my self whether I can drop the latency, whith using native fullscreen.

          1 Reply Last reply
          0
          • timdayT Offline
            timdayT Offline
            timday
            wrote on last edited by
            #5

            Interesting problem... I had a project which worried about that sort of stuff back in the days of AGP graphics cards... (back then we found transfers to/from a GPU card could be done significantly faster using DirectDraw than by using Direct3D or GDI APIs. Think DirectDraw has been deprecated since though, and the Windows driver model is all changed now).

            One thought... the difference between your best 65ms and QML's 80ms is suspiciously close to 16ms and (probably) your monitor's 60Hz refresh rate. Suggests there could be an extra vsync delay getting in there or something. Might be interesting to see if messing with QSurfaceFormat::SwapBehavior (via QWindow::setFormat) changes anything (and/or setting QSurfaceFormat::setSwapInterval to zero... not sure how the two interact.

            1 Reply Last reply
            0

            • Login

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • Users
            • Groups
            • Search
            • Get Qt Extensions
            • Unsolved