david7a68 / plinth Goto Github PK

Something like < 500ms for an incremental build?

Probably also need something for a fresh build, though that's made much more difficult with the windows crate.

• any decisions that are made on startup (allocation sizes, configuration, etc).
• key milestones
  • GPU initialization
  • loading of static resources
  • etc.

Instead of DrawInstanced(4, num_rects, 0, rect_start), use DrawInstanced(6 * num_rects, 1, rect_start * num_rects, 0).

This supposedly is a performance improvement for small meshes, of which a rect definitely qualifies.

• Event: battery alert (low, normal)
  • Add callback in event handler
  • Pick up and forward events from Windows
• Event: power source change (internal, backup, external)
  • Add callback in event handler
  • Pick up and forward events from Windows
• Event: monitor state change (on, dimmed, off)
  • Add callback in event handler
  • Pick up and forward events from Windows
• Event: power preference change (performance, balanced, power)
  • Add callback in event handler
  • Pick up and forward events from Windows

• sketch out API
• add operation to canvas
• implement DirectWrite backend
• profit?

This would require corresponding adjustments in upload heap size.

Windows should be able to register to be repainted in a way that synchronizes with the compositor.

• xywh: i16Q4x4 (-16383 to 16384 with 2 fractional bits (0.0, 0.25, 0.75, 1.0))
  • 2 * 4 = 8 bytes
• uvwh: u12x4
  • 6 bytes
• rgba: f16x4
  • 2 * 4 = 8 bytes
• itex: u8 (max 256 textures)
  • 1 byte
• flag: u8
  • 1 byte

Total: 24 bytes

With Rounding:

• bevl: i16Q4x4
  • 2 * 4 = 8 bytes

Total: 24 + 8 = 32 bytes

With gradients and rounding:

• rgba: `[f16x4; 2]' (2-point gradient, add a second color)
  • 2 * 4 * 2 = 16 bytes
• grad: `[i16Q4x2; 2]'
  • 2 * 2 * 2 = 8 bytes

Total: 32 + 16 = 48 bytes

With gradients, rounding, and rotation:

• rotp: i16Q4x2 (center of rotation)
  • 2 * 2 = 4 bytes
• rotr: f16 (radians of rotation)
  • 2 bytes

Total: 48 + 6 = 54 bytes

This size must be aligned to the size of float4 which leaves us with 64 bytes per primitive and 10 bytes to play with.

Other extra features

• 7 bytes for a second texture to support masking/clipping to another texture.
• 2 bytes to describe hollowness (to render only a border)
• reduce bevel from 4 corners to 2 and use a flag to choose between horizontal and vertical to save 4 bytes
• horizontal shear with 2 bytes
• edge softness with 2 bytes

Implementing all of those features would take up 63 bytes (still 1 byte free!).

For simplicity, and because that's probably what we're going to need for the UI anyway.