Clarified this a bit to make it discoverable with grep.

Python code to write out HTML and SVG, except it's rust because the input is serde.

After the chat in Berlin about coordinate transforms, I will fix this :^)

This was necessary to get things compiling, but it's highly suspicious I'm the only one who needs a pub here even though there's plenty pub use crate stuff below. If there's a proper way to do this please let me know!

I tried implementing a manual serializer method to make this nicer, but couldn't make it work (nesting maps and sequences). So using derive and a lot of skip instead.

frames is always allocated, but when the user pref is false, we never write anything to it. So that's probably ok and simplest.

This gets added to the prims when visualizing, and that fixes everything being bunched up at (0,0), which makes the web content overlap with the UI chrome. However it breaks down under scrolling.

This origin ultimately comes from unclipped in take_context, see below.

You're right, even though I only add these after the compiler complains that I need one. I should probably re-read the chapter on ownership :)

This one complains about "cannot move out of invalidation reason which is behind a shared reference".

Sure, the problem is that tileview can't see the picture imports:

@DESKTOP-02TEENE /c/code/1605283_tilecache/gfx/wr/tileview
$ cargo build
   Compiling webrender v0.60.0 (C:\code\1605283_tilecache\gfx\wr\webrender)
   Compiling tileview v0.1.0 (C:\code\1605283_tilecache\gfx\wr\tileview)
error[E0603]: module `picture` is private
 --> tileview\src\main.rs:4:16
  |
4 | use webrender::picture::{TileDescriptor, TileId, TileNode, TileNodeKind, InvalidationReason};
  |                ^^^^^^^

But I imagine that wrench needs them too, so I'm wondering how wrench got access to those.

Good idea; I didn't do it at first because Rust doesn't have inner structures, but, it's not the end of the world to have another module-global type.

Well, I'm trying to keep the prims in local space, and apply their local-to-world transform in tileview, just before writing out the SVG coordinates. That way, when scrolling, their local space coordinates don't change, only the transform does (shifting the parent picture around on the viewport). Thus diffing works as intended -- the primitives aren't moving inside the tile, the tile is not being invalidated, and so we don't want the primitives to flash bold red in the viewer.

That's the idea, the only flaw is that the local to world transform is not accurate enough, I'm hacking it with a 2D translation by unclipped.origin.

Yes, see earlier note, ideally we keep the prims as is and export their mapping to viewspace along with them. That transform is what unclipped.origin is meant to represent.

Sure, but it's a 700+ line function and most of it would be a bug if a var goes unused, so I think the extra cfg not is safer?

I actually started out doing a manual implementation, until I realized how much work that would be (plus some problems combining SerializeMap and SerializeStruct), and how awesome it is that Rust has Serde&Derive... so it's a bit sad if we can't use it :(

Let me move the ~Tiny serializer structures into picture.rs, and use those, and see what it looks like after that in terms of skip spam and compile slow downs?

Let's add #[derive(Copy, Clone] to the InvalidationReason enum. That means that type is treated as a value type that is copied, rather than moved. This often simplifies code and I usually mark any time < 16 bytes or so as Copy, not sure why I didn't here!

The use line in tileview can be:

use webrender::{TileDescriptor, TileId, TileNode};

This means that it uses the types you publicly export in this lib.rs, whereas you're directly referencing a type inside the private picture module in that compile error.

Not quite sure I follow this bit - might be easier to discuss this bit on slack / matrix.

Yup, sounds fair enough!

Yep, we should definitely keep serde if we can use those Tiny structs!

I've tried and it felt like things got less readable. Not sure, maybe I was doing it wrong.

Ok, done!

Meh :)

Ah, I see -- the pub use create::picture::Foo part in lib.rs acts as an export of some sorts. Thanks!

Yeah I might not be making a lot of sense here. Maybe we can set up a Zoom if you have 30 mins or so to cover what info you'd like to get out of the interning tables, and this coordinate transform business?
Code review wise I'll land it as-is for now, ie. "slightly buggy but ballpark".