Search Unity

Help Wanted Need a alternative to GUI.DrawTexture

Discussion in 'Scripting' started by EthanIsHere5533, Sep 17, 2021.

  1. EthanIsHere5533

    EthanIsHere5533

    Joined:
    Jun 29, 2015
    Posts:
    2
    I am currently working on a custom editor window in which I am editing a texture2d with get and set pixels and was getting very slow response times. At first, I thought it was the texture 2d as I have had performance issues with it before. But, I put in some timers and it turned out to be GUI.DrawTexture. Any alternative that would work in the editor.
     
  2. Cameron860

    Cameron860

    Joined:
    Jun 1, 2009
    Posts:
    814
    No simple drop in "this is faster" replacement that I'm aware of. Your options will depend on what outcome you're trying to achieve. Also, use the profiler rather than timers. It's very easy to capture the wrong info using timers.
     
  3. EthanIsHere5533

    EthanIsHere5533

    Joined:
    Jun 29, 2015
    Posts:
    2
    Looking at the profiler it makes it seem as if GUI.DrawTexture is not taking that long but in my tests, it takes a noticeable amount of time after the texture is updated for the window to also update. Also, if it helps the plan is to make a grid-like texture and edit it using mouse inputs to select an area on some sprite that I can reference later. If you have any better ideas on how to approach this I am totally open.
     
  4. Cameron860

    Cameron860

    Joined:
    Jun 1, 2009
    Posts:
    814
    Sounds like you need to identify where the bottleneck is.

    Are you working in a custom editor window?

    Are you only making a single call to GUI.DrawTexture or per grid square? If so, how many grid squares?

    Is the issue you're facing that you're trying to make an interactive tool but the editor isn't re-drawing fast enough?

    If yes, perhaps you just need to call EditorWindow.Repaint() after processing mouse input.

    What's not apparent with OnGUI is that it's called a minimum of 2 times per frame (with a layout event at the start and repaint even at the end) + once for each other event (mouse move, key down etc) in between those two events. So for complex editors I always start OnGUI with switch on Event.current and branch any heavy drawing to only happen if the event type is Repaint.
     
  5. Bunny83

    Bunny83

    Joined:
    Oct 18, 2010
    Posts:
    1,114
    Like Cameron already said, all editor windows only update when they need to. This could be caused by a tooltip timeout when you hover over your window or when the underlying system requests a repaint. So you have to call Repaint yourself.

    You can do this but this can cause all sorts of issues when you mix GUI and GUILayout stuff in the same editor. Also some things require the layout event as well like GUI.Window, even when you only use GUI functions. Also you should not filter out everything but the repaint event but go the other way round and filter out just the layout event. The layout event is paired with every event that is processed. key and mouse events included. Of course if you have a pure drawing section that may even use other drawing API (like Unity's GL class or Camera.Render) this must be restricted to the Repaint event.

    Note that most GUI functions already check the current event type internally. So calling GUI.DrawTexture does nothing during the layout event. Maybe have a look at my IMGUI crash course. Or if you have some time, check out my UVViewer as an example.
     
    Cameron860 likes this.
  6. Cameron860

    Cameron860

    Joined:
    Jun 1, 2009
    Posts:
    814
    Thanks for the clarification @Bunny83 , I don't think I explained the OnGUI event stuff very clearly.
     
unityunity