this.root.scrollRect

#1

Whem you start change the this.root.scrollRect value like this:

 this.root.scrollRect = this.yourSprite.getRect(this);

the frame rate drops from 61 to 30 or less, on the new update of openfl 5.1.5 to 8.1.1
and lime 5.2.1 to 6.3.1

it was working on openfl 4.2.0 and lime 3.2.1

#2

Can you tell if this is a hardware OpenGL target, or if you are running in Canvas or Cairo? Are you setting the scrollRect to the size of the stage, smaller or larger?

#3

how can i change between opengl, canvas and cairo to compile and test?

Like this?:

 openfl test windows -cairo?
#4

Almost, it’s -Dcairo (and -Dcanvas).

#5

this take effect to windows target too?

#6

This is how it look with openfl 5.1.5 to 8.1.1
and lime 5.2.1 to 6.3.1:
Capture01

openfl 4.3.0 lime 3.2.1
Capture00

#7

I use sprite.graphics.moveto, lineto, etc, to draw every color inside every tile.

The first image just got like that whem i move the camera using scrollRect

#8

is windows target,
the sprite cam have the width and height of the stage.stagewidht and stage.stageheight

#9

now i use the width and height of the window 870w / 512h
for the sprite cam and pass this to the scrollRec but still have the same problem, drop frame rate and strange drawining:
Video

#10

ok. the scrollRect is not the problem, if i comment all the camera code, all the sprites that are moving got this strange draw

#11

Have you considered using Bitmap or Tilemap instead of graphics drawing? Pretty sure they’re faster on Windows.

#12

Ah, I recognize this.

It’s this issue:

I’d like to know what calls you make in a single Graphics object. Are they lines, or all drawRect or lineTo?

drawQuads would perform better, but it would be good to know what APIs you are using now, I’d love a reproduction case on the seams and it would help us know what APIs to try and prioritize when we add HW acceleration to more APIs

#13

Im using drawRect.

drawQuads still dont implemented at openfl 6.2.0

openfl 6.2.0
lime 5.6.0
hxcpp 3.2.102

#14

Thanks,

Would you mind sharing the full list used in the game display, as you’ve shown?

beginFill ()
drawRect ()

Is that it? Any other fill types, or lineTo, or other calls? :slight_smile:

#16

just this:

sprite.graphics.beginFill(color);
sprite.graphics.drawRect(newX, newY, tileSize, tileSize);
#17

i try with moveTo, lineTo, but got the same result

#18

The old, old version of OpenFL was hardware accelerated when using drawRect, it ran faster but there were many cases where it was not accurate. We rewrote the renderer, and went for a canvas/cairo software render for vector shapes. The good news is that this is much more accurate for complex graphics, the downside is that a simple drawRect is no longer hardware accelerated, or wasn’t before OpenFL 8.

OpenFL 8 added hardware accelerated support for drawQuads, which will batch multiple rectangles into one draw call, similar to drawTriangles (which is hardware accelerated again, too). drawRect and beginFill (only) are hardware accelerated again, and we have a TODO to add other drawRect fills as well as other kinds of geometry.

It may be worth giving OpenFL 8 a try, I understand there are audio improvements you need that are not in OpenFL 8, but you could give the rendering a try and see how the performance compares, and we figure out the SAMPLE_DATA feature?

Definitely want to help

1 Like
#19

I will try right now, thanks! really apreciate your time.

#20

with openfl 8.1.1 drawRect is getting 6fps,
will try drawQuads now

#21

Openfl 8.1.1
lime 6.2.1
hxcpp 3.4.188

Try drawQuads, the frame rate gets better, but the issue with graphics persist:
video