~eliasnaur/gio

Changelist affine transforms

Details
Message ID
<CABgUa+2tHZSpWLXY61t0O1Sd_=G4G798TdrikwZnAG6n2pSZwQ@mail.gmail.com>
DKIM signature
pass
Download raw message
Elias,

I just sent out a series of patches that together implement affine
transforms. I just thought that I should give you some more info to
make the review easier:

Patch 1:
- relatively straight forward, you have mostly seen this before,
  what is new from last time (fixes the test failures you had) is
  that I have also removed the 0 width optimization and closed all
  curves, this will be needed for transforms anyway

Patch 2:
- creating the affine package. Now updated to using the 0-value is
  identity again as you asked last time. Also moved the origin args
  first, I have however opted for keeping both Scale and ScaleAround
  variants as I still think they will be very user friendly and they
  are hidden in a type and thus do not pollute the global api of the
  package anyway. Let me know if you still disagree about this.

Patch 3:
- use f32.Affine2D for handling the transforms internally, but still
  only support simple transforms. You have mostly seen this before.

Patch 4:
- update the gpu code to support full affine transformations and
  expose this to the user through the op package.

Patch 5:
- add a larger set of test cases for the integrated drawing pipeline
  (i.e. use package op and package gpu). These can probably be
  complemented by more cases down the line, but at least catch all the
  different bugs I have encountered while trying to get this to work.
  Note that I here check for pixel-exact matches to reference images
  committed to the repository - I do not know if this is too fragile (
  will e.g. get different results on different platforms). I do however
  think that I makes sense to have these sorts of tests since it makes
  modifying any of the rendering code much easier, and it is easy to update
  the reference images for minor aliasing changes etc (differences will
  be dumped by the test).

Patch 6:
- highly optional, but update the kitchen example to show of the, it does
  add a dependency for github.com/vron/gease for the example though - your
  call as to if you want to keep it or not.

As a general overall comment: I have opted for simplicity in the changes no
rather than full optimization, there is some relatively low hanging fruit
(see commit message), but suggest that is done as a separate exercise.

I have used the benchmark in internal/rendertest to at least make sure
that there are not major changes in performance for simple-transform
only cases as compared to master (bench ran for 1m each)
Latest master:
BenchmarkShapesAndText-24          35338           2013951 ns/op
  1056965 B/op        219 allocs/op
After this series of patches:
BenchmarkShapesAndText-24          30470           2357033 ns/op
  1055664 B/op        217 allocs/op
I believe the changes we see here are mostly due to less re-use of GPU
buffers for transformed (offset only) objects. As previously noted this
is possible to fix with using the affine transforms to, but I would suggest
to do this at the same time as buffering the cpu transform / split operations.

Regards
/V
Export thread (mbox)