Save
Saving
  • linus

    Thank you. I will raise an issue.
    Interested to see if you, or anyone else can notice the same thing.
    The difference is very subtle, but hopefully you will be able to access and measure more accurately and see actual numbers.

    posted in Kode read more
  • linus

    I'm testing and comparing html5 build and native macOS build, and the native build feels slightly less responsive compared to the html5 build.

    This is hard to quantify because the difference is so small, and I feel like I'm going crazy trying to test this, but I do notice a difference.

    I'm testing the same keyboard inputs and expect the same results on both builds, and the difference is most noticable when switching from the html5 build to the native build.
    I do most of the testing using html5 because it builds faster, and the times I created a native build to ensure that everything works the same I noticed that the native build "feels" more sluggish and unresponsive.
    Screen updates seems fast and performance in general seems snappy, just that the response to key inputs seems slightly slower.

    Overall the html5 build seems most responsive.
    Windowed native build using metal feels least responsive.
    Fullscreen native build using metal feels more responsive, but it's hard to tell if it is same as html5.
    Native build using opengl feels more responsive in both window and fullscreen, but it's hard to tell if it is same as html5.

    I have tried to add timers to the code and measure time between inputs and update/render calls, but I don't see anything of concern, and the native build has shorter times from capturing the input to the next update.
    So if there is a delay/lag anywhere it seems like it would be before the key input reaches my code.
    I have looked at the numerical values produced by my code, and apart from minor rounding differences, all builds seems to result in the same values, so the code itself should be behaving same on all builds.

    Is this expected or known?
    Is there something that could cause this?
    Is there something I can do to solve this?
    Am I crazy?

    posted in Kode read more
  • linus

    I'm doing some testing with macos native build and I noticed an issue when manipulating the window.
    I isolated the issue enough to reproduce it fairly consistently by running compiled build, using macos fullscreen function to make the app fullscreen, then toggling mission control which will move the fullscreen up to the desktop panel at the top of the screen. I use ctrl+↑ to trigger mission control, and after doing this a couple of times the app will freeze.
    When the issue happens, system will say that the app is unresponsive and all calls to update and render stops and I will need to force quite the application because the window controls no longer slide down when moving my cursor to the top of the screen.
    There is no spike in processor usage.
    I don't see any errors in the terminal.

    The project I am testing with is https://github.com/Kha-Samples/Empty.git, and only modification is three lines to render to draw something on screen -

    static function render(framebuffer: Framebuffer): Void {
    	framebuffer.g2.begin();
    	framebuffer.g2.fillRect(100, 100, 32, 32);
    	framebuffer.g2.end();
    }
    

    I originally had loops that would draw hundreds of items on screen, and the issue seemed to happen faster when there was more drawing, but it still happens with this single rectangle.

    I am using XCode Version 10.1 (10B61) on macOS Version 10.14.3 (18D109).
    I tried to run the compiled build on another macbook with macos older than mojave, and I was unable to reproduce on that machine.

    Is this something that is known? Is there anything I can do to avoid this issue?

    posted in Kode read more