Implement Graphics.drawGraphicsData and readGraphicsData

[roncarbot]

Summary

• Implements Graphics.drawGraphicsData() by walking IGraphicsData items (data_type) and dispatching to the existing beginFill / beginGradientFill / beginBitmapFill / endFill / lineStyle / lineGradientStyle / lineBitmapStyle / drawPath machinery.
• Implements Graphics.readGraphicsData() for this Graphics object (no display-list recurse). Recorded fill/stroke paths survive tessellation/endFill so a solid fill + path can round-trip. Output uses SolidFillStyle / GradientFillStyle / BitmapFillStyle, GraphicsEndFill, GraphicsStrokeStyle, and GraphicsPath with MOVE_TO / LINE_TO / CURVE_TO only.
• Adds GraphicsEndFill ([graphicsdata EndFill]). Existing drawing APIs are unchanged.

Test plan

• beginFill + drawPath/drawRect then readGraphicsData() returns a solid fill, path, and end fill
• drawGraphicsData() of that result redraws the same shape
• lineStyle + path round-trips a GraphicsStrokeStyle + path
• clear() drops recorded data
• Existing beginFill / lineTo / endFill drawing still works

[rob-bateman]

@roncarbot you return newmat here but if you have a transform don't you need to return the correct _bitmapMaterialTransform material. what eventualities is the image arg used?

[roncarbot]

Good catch to double-check. When image is set we intentionally return a per-image material (image.id + transform flag), not the shared _bitmapMaterialTransform. The shared transform material is only the fallback for the no-image path below (default 8×8 placeholder + animateUVs).

image is used for author-time / beginBitmapFill bitmaps so each BitmapData gets its own material (and its own mip/NPOT handling) instead of all fills fighting over one shared material. The transform flag on that path only turns on animateUVs for that per-image material — same UV-animation behaviour as _bitmapMaterialTransform, without sharing the texture slot.

[rob-bateman]

a per-image material is not needed, the material is only holding shader information (which is the same for every bitmap material) and the image is set on the style property of the shape. If you look at where getMaterialForBitmap() is implemented, it is accompanied by a style.image setting when appropriate

[roncarbot]

You're right — I was over-fitting. Materials here are shared shader state; the bitmap belongs on style.image (both GraphicsFactoryFills and the ShapeTag path already set that). I've dropped the per-image material pool and the extra image arg; getMaterialForBitmap(transform) is back to the shared _bitmapMaterial / _bitmapMaterialTransform pair. Kept the mipmap=false sampler change, which was the part that actually fixed the black NPOT fills.

[rob-bateman]

I don't think sourceGraphics is being used for anything, can you check and if not, remove from source?

[roncarbot]

It is still used — three places in this file:

1. start / end getters fall through to sourceGraphics when this instance hasn’t set its own.
2. copyTo sets graphics.sourceGraphics = this so clones keep a link back to the symbol Graphics.
3. readGraphicsData (this block) — if the instance has no queued ShapeTags, no shapes, and no recorded fill paths, it reads from sourceGraphics so timeline instances that share / clone a symbol still reconstruct fills.

Happy to rename or tighten the fallback if you’d rather readGraphicsData only ever look at this, but I wouldn’t remove the field while those three paths still need it.