What exactly does gfx.update do?

[Dsharpmaj]

And do I really need to call it?

[Xenakios]

It redraws the GUI window your script may have opened.

[Meo-Ada Mespotine]

When you open a window with gfx.init and you draw into it, you need to call gfx.update or otherwise, your drawn-stuff will not be shown.
Especially with defer-scripts, this is important.

It has the great benefit, that you can draw your stuff first, before actually showing it.
Otherwise, when seeing every element drawn at the time of calling of the drawing-function, this would cause flickering graphics.

[Fabian]

Originally Posted by mespotine

When you open a window with gfx.init and you draw into it, you need to call gfx.update or otherwise, your drawn-stuff will not be shown.
Especially with defer-scripts, this is important.

It has the great benefit, that you can draw your stuff first, before actually showing it.
Otherwise, when seeing every element drawn at the time of calling of the drawing-function, this would cause flickering graphics.

Is this really the case? That we "need to call gfx.update or otherwise, [the] drawn-stuff will not be shown".

I am experimenting with Lua scripts, and everything seems to work fine whether I call gfx.update() on each defer or not. In fact, your own demo code here https://forum.cockos.com/showpost.ph...12&postcount=7 does not have any gfx.update() in sight, yet it works flawlessly.

There is probably something that I'm missing, but I cannot see what...

[Lokasenna]

It may depend on how you're handling the UI. My GUI blits the entire window when it updates itself, so removing gfx.update doesn't appear to affect anything.

[Xenakios]

Originally Posted by Fabian

There is probably something that I'm missing, but I cannot see what...

What operating system are you on? (Mac Os might be doing automatic window updates.) Are you using gfx.blit?

[tack]

My understanding is that gfx.update() doesn't actually draw anything, but refreshes the various gfx variables based on current window position, mouse position, dock state, etc.

I think these get updated implicitly anyway, but update() forces it to be current at the time of invocation. I agree this isn't very clear from the documentation.

[Lokasenna]

For what it's worth, on Linux this code erases the previous content correctly:

gfx.init()

local str = "Hello!"
local str_w, str_h = gfx.measurestr(str)

local function Main()
  local char = gfx.getchar()
  if char == -1 or char == 27 then
    gfx.quit()
    return
  end

  gfx.x = math.random() * (gfx.w - str_w)
  gfx.y = math.random() * (gfx.h - str_h)
  gfx.drawstr(str)

  reaper.defer(Main)
end

Main()

[Lokasenna]

I think these get updated implicitly anyway, but update() forces it to be current at the time of invocation. I agree this isn't very clear from the documentation.

How would they ever not be up to date if Reaper is updating them implicitly?

[tack]

Originally Posted by Lokasenna

How would they ever not be up to date if Reaper is updating them implicitly?

For example if you call some API that moves the window, gfx.{x,y} would be stale until gfx.update() is called (or until the next defer cycle).

That's my hypothesis anyway.

[dsyrock]

Recently I'm writing a script with. And I found that when there is gfx.update() in my code, the function gfx.getdropfile doesn't work anymore. And it works again after deleting gfx.update(). That is weird.

[tack]

Originally Posted by dsyrock

Recently I'm writing a script with. And I found that when there is gfx.update() in my code, the function gfx.getdropfile doesn't work anymore. And it works again after deleting gfx.update(). That is weird.

gfx.update() does seem to clear the dropfile list. So you need to call gfx.getdropfile() before gfx.update() in your defer handler.

[spk77]

Originally Posted by tack

My understanding is that gfx.update() doesn't actually draw anything, but refreshes the various gfx variables based on current window position, mouse position, dock state, etc.

I think these get updated implicitly anyway, but update() forces it to be current at the time of invocation. I agree this isn't very clear from the documentation.

I'm quite sure that a few months (years?) ago, gfx.mouse_x and gfx.mouse_y didn't update without calling gfx.update().

[Meo-Ada Mespotine]

Originally Posted by Fabian

Is this really the case? That we "need to call gfx.update or otherwise, [the] drawn-stuff will not be shown".

I am experimenting with Lua scripts, and everything seems to work fine whether I call gfx.update() on each defer or not. In fact, your own demo code here https://forum.cockos.com/showpost.ph...12&postcount=7 does not have any gfx.update() in sight, yet it works flawlessly.

There is probably something that I'm missing, but I cannot see what...

The behavior has changed in the meantime, though I don't know how much. I think it also has something to do with the massive overhaul in gui/retina/graphics-stuff so my claim may not be 100% accurate anymore.

I personally would say, use it. As long as the devs don't deprecate the function, there are probably things where it's actually needed.

Originally Posted by spk77

I'm quite sure that a few months (years?) ago, gfx.mouse_x and gfx.mouse_y didn't update without calling gfx.update().

Yes, this was changed in the meantime too, afair somewhere in the last year.
gfx.mousecap too IIRC.

Originally Posted by tack

gfx.update() does seem to clear the dropfile list. So you need to call gfx.getdropfile() before gfx.update() in your defer handler.

Good to know, I will add that into my ReaScript-docs as useful information.