love.graphics.newQuad not so slow?

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
User avatar
Ref
Party member
Posts: 702
Joined: Wed May 02, 2012 11:05 pm

love.graphics.newQuad not so slow?

Post by Ref »

Was surprised by two things.
The WIKI says the love.graphics.newQuad is:
"This function can be slow if it is called repeatedly, such as from love.update or love.draw. If you need to use a specific resource often, create it once and store it somewhere it can be reused! "
I guess 'slow' is a relative term - see demo.
The second surprise was when trying to accomplish the same effect using imageData and paste.
This approach was slower and resulted in a continuous increase in memory usage - ultimate ending in the script stopping dead in the water due to lack of memory. Had to add a garbagecollection step (with resulting periodic hic-up.)
Thought garbagecollection would have been done automatically.
Attachments
scroll.love
Simple image scroll test
(68.99 KiB) Downloaded 116 times
User avatar
stampede247
Prole
Posts: 11
Joined: Thu May 02, 2013 8:21 pm
Location: United States
Contact:

Re: love.graphics.newQuad not so slow?

Post by stampede247 »

Well i'm not sure of the specifics but I left it running for about 45 minutes on my computer, came back and the framerate had dropped from around 980 to between 930 and 940. So something might be slowly slowly bogging it down but idk if that's big enough to really consider
User avatar
slime
Solid Snayke
Posts: 3159
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: love.graphics.newQuad not so slow?

Post by slime »

The performance difference between 940fps and 980fps is the same as the performance difference between 60fps and 60.15fps.

Quads don't have a lot of data associated with them or a lot of calculations done when creating them, so newQuad isn't very slow as far as the new* functions go, however as a rule of thumb you shouldn't call new* in love.update or love.draw. Quad:setViewport exists if you want to change the Quad's information after creation.

A single 512x512 ImageData uses 1MB of RAM, and Lua's garbage collector can take a little while before freeing memory of objects in the "garbage", so it can balloon really fast if you create ImageDatas every frame, unless you explicitly call collectgarbage("collect").
User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: love.graphics.newQuad not so slow?

Post by bartbes »

slime wrote:however as a rule of thumb you shouldn't call new* in love.update or love.draw
(unconditionally)
slime wrote: A single 512x512 ImageData uses 1MB of RAM, and Lua's garbage collector can take a little while before freeing memory of objects in the "garbage", so it can balloon really fast if you create ImageDatas every frame, unless you explicitly call collectgarbage("collect").
Let's not forget that creating an Image from it will upload it to your gpu, which is a relatively slow operation, and typically pauses any computations done on the gpu.
User avatar
Ref
Party member
Posts: 702
Joined: Wed May 02, 2012 11:05 pm

Re: love.graphics.newQuad not so slow?

Post by Ref »

Thanks Slime & Bartbes!
Exactly the info I was looking for.
Really didn't know exactly what Quad:setViewport() did.
In this very limited case, using setViewport or newQuad doesn't seem to be frame rate limiting.
Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 3 guests