[fb] optimize dithering for WHITE and BLACK

[mrichards42]

I've noticed that some of the remarkable_puzzle animations are super slow, so I've been doing some profiling. draw_rect and whichever dithering function I use together take up about 90% of the time according to gprof, so I'm focusing on those :)

One pretty simple optimization is skipping dithering for WHITE and BLACK colors -- the dithering matrices are normalized so that they add or subtract less than 50% of the difference between two colors (so, e.g. in 2-color dithering 0.0 is shifted to between -0.49 and 0.49, which rounds back to 0.0 in all cases).

This change gives me between a 2x and 5x speedup in dithering, depending on how much gray is being drawn:

A sample of lightup, which uses a lot of gray:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 45.86 1.22 1.22 24576951 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
39.47 2.27 1.05 1253836 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
# after
% cumulative self self total time seconds seconds calls ms/call ms/call name 54.08 1.06 1.06 1259815 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
31.12 1.67 0.61 27939892 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

A sample of untangle, which is almost all black and white:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 61.84 7.34 7.34 165550334 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
35.89 11.60 4.26 2498395 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
% cumulative self self total time seconds seconds calls ms/call ms/call name 78.94 5.51 5.51 3671557 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
16.48 6.66 1.15 240161310 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

I'd also be happy to add these as separate dithering modes (e.g. BAYER_BW_2 or something), in case we want to let users opt in to this behavior. If you were rendering a grayscale bitmap, for instance, this is probably unhelpful, and just adds 2 extra comparisons per pixel.

[raisjn]

this seems reasonable, thanks!

regarding animations and potential slow down, also see ddvk/remarkable2-framebuffer#42. if the rm2fb queue is filled, it will cause delay in painting until the queue settles (this is contrary to how rm1 worked, i believe).

if you turn on DEBUG in the rm2fb client/server code, you can see the update requests and draw timings - an example output can be seen here: ddvk/remarkable2-framebuffer#38 (comment). this will let you get a sense of how much repainting a particular region costs with a particular waveform.

[raisjn]

i just played with the release build with these changes, the performance is good! i had been using the debug build previously, so was very happy to see release build perf - i think it feels pretty snappy for an e-reader

(i also think the rm2fb queue getting filled is not the issue after doing some small testing)

[mrichards42]

Awesome! Yeah, it's pretty decent with a release build. Agreed that I don't think it's an issue w/ the rm2fb queue -- although that might have been part of the trouble I had w/ the dithering demo.

[raisjn]

i'm curious if #78 speeds up drawing at all for you

• uses draw_rect_fast which doesn't call update_dirty (which does a bunch of extra work for each pixel)
• uses likely/unlikely
• split rectangle drawing into separate cases: one case for fill, one for non-fill. non-fill is now O(N+M) instead of (N*M)

i am unsure of how you did your profiling cases above - is it just a single render? (or X renders?) of a game scene? or does it involve manual interaction with the game?

[mrichards42]

I've noticed that some of the remarkable_puzzle animations are super slow, so I've been doing some profiling. draw_rect and whichever dithering function I use together take up about 90% of the time according to gprof, so I'm focusing on those :)

One pretty simple optimization is skipping dithering for WHITE and BLACK colors -- the dithering matrices are normalized so that they add or subtract less than 50% of the difference between two colors (so, e.g. in 2-color dithering 0.0 is shifted to between -0.49 and 0.49, which rounds back to 0.0 in all cases).

This change gives me between a 2x and 5x speedup in dithering, depending on how much gray is being drawn:

A sample of lightup, which uses a lot of gray:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 45.86 1.22 1.22 24576951 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
39.47 2.27 1.05 1253836 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
# after
% cumulative self self total time seconds seconds calls ms/call ms/call name 54.08 1.06 1.06 1259815 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
31.12 1.67 0.61 27939892 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

A sample of untangle, which is almost all black and white:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 61.84 7.34 7.34 165550334 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
35.89 11.60 4.26 2498395 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
% cumulative self self total time seconds seconds calls ms/call ms/call name 78.94 5.51 5.51 3671557 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
16.48 6.66 1.15 240161310 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

I'd also be happy to add these as separate dithering modes (e.g. BAYER_BW_2 or something), in case we want to let users opt in to this behavior. If you were rendering a grayscale bitmap, for instance, this is probably unhelpful, and just adds 2 extra comparisons per pixel.

[raisjn]

this seems reasonable, thanks!

regarding animations and potential slow down, also see ddvk/remarkable2-framebuffer#42. if the rm2fb queue is filled, it will cause delay in painting until the queue settles (this is contrary to how rm1 worked, i believe).

if you turn on DEBUG in the rm2fb client/server code, you can see the update requests and draw timings - an example output can be seen here: ddvk/remarkable2-framebuffer#38 (comment). this will let you get a sense of how much repainting a particular region costs with a particular waveform.

[raisjn]

i just played with the release build with these changes, the performance is good! i had been using the debug build previously, so was very happy to see release build perf - i think it feels pretty snappy for an e-reader

(i also think the rm2fb queue getting filled is not the issue after doing some small testing)

[mrichards42]

Awesome! Yeah, it's pretty decent with a release build. Agreed that I don't think it's an issue w/ the rm2fb queue -- although that might have been part of the trouble I had w/ the dithering demo.

[raisjn]

i'm curious if #78 speeds up drawing at all for you

• uses draw_rect_fast which doesn't call update_dirty (which does a bunch of extra work for each pixel)
• uses likely/unlikely
• split rectangle drawing into separate cases: one case for fill, one for non-fill. non-fill is now O(N+M) instead of (N*M)

i am unsure of how you did your profiling cases above - is it just a single render? (or X renders?) of a game scene? or does it involve manual interaction with the game?

[mrichards42]

I've noticed that some of the remarkable_puzzle animations are super slow, so I've been doing some profiling. draw_rect and whichever dithering function I use together take up about 90% of the time according to gprof, so I'm focusing on those :)

One pretty simple optimization is skipping dithering for WHITE and BLACK colors -- the dithering matrices are normalized so that they add or subtract less than 50% of the difference between two colors (so, e.g. in 2-color dithering 0.0 is shifted to between -0.49 and 0.49, which rounds back to 0.0 in all cases).

This change gives me between a 2x and 5x speedup in dithering, depending on how much gray is being drawn:

A sample of lightup, which uses a lot of gray:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 45.86 1.22 1.22 24576951 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
39.47 2.27 1.05 1253836 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
# after
% cumulative self self total time seconds seconds calls ms/call ms/call name 54.08 1.06 1.06 1259815 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
31.12 1.67 0.61 27939892 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

A sample of untangle, which is almost all black and white:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 61.84 7.34 7.34 165550334 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
35.89 11.60 4.26 2498395 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
% cumulative self self total time seconds seconds calls ms/call ms/call name 78.94 5.51 5.51 3671557 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
16.48 6.66 1.15 240161310 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

I'd also be happy to add these as separate dithering modes (e.g. BAYER_BW_2 or something), in case we want to let users opt in to this behavior. If you were rendering a grayscale bitmap, for instance, this is probably unhelpful, and just adds 2 extra comparisons per pixel.

[raisjn]

this seems reasonable, thanks!

regarding animations and potential slow down, also see ddvk/remarkable2-framebuffer#42. if the rm2fb queue is filled, it will cause delay in painting until the queue settles (this is contrary to how rm1 worked, i believe).

if you turn on DEBUG in the rm2fb client/server code, you can see the update requests and draw timings - an example output can be seen here: ddvk/remarkable2-framebuffer#38 (comment). this will let you get a sense of how much repainting a particular region costs with a particular waveform.

[raisjn]

i just played with the release build with these changes, the performance is good! i had been using the debug build previously, so was very happy to see release build perf - i think it feels pretty snappy for an e-reader

(i also think the rm2fb queue getting filled is not the issue after doing some small testing)

[mrichards42]

Awesome! Yeah, it's pretty decent with a release build. Agreed that I don't think it's an issue w/ the rm2fb queue -- although that might have been part of the trouble I had w/ the dithering demo.

[raisjn]

i'm curious if #78 speeds up drawing at all for you

• uses draw_rect_fast which doesn't call update_dirty (which does a bunch of extra work for each pixel)
• uses likely/unlikely
• split rectangle drawing into separate cases: one case for fill, one for non-fill. non-fill is now O(N+M) instead of (N*M)

i am unsure of how you did your profiling cases above - is it just a single render? (or X renders?) of a game scene? or does it involve manual interaction with the game?

[mrichards42]

I've noticed that some of the remarkable_puzzle animations are super slow, so I've been doing some profiling. draw_rect and whichever dithering function I use together take up about 90% of the time according to gprof, so I'm focusing on those :)

One pretty simple optimization is skipping dithering for WHITE and BLACK colors -- the dithering matrices are normalized so that they add or subtract less than 50% of the difference between two colors (so, e.g. in 2-color dithering 0.0 is shifted to between -0.49 and 0.49, which rounds back to 0.0 in all cases).

This change gives me between a 2x and 5x speedup in dithering, depending on how much gray is being drawn:

A sample of lightup, which uses a lot of gray:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 45.86 1.22 1.22 24576951 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
39.47 2.27 1.05 1253836 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
# after
% cumulative self self total time seconds seconds calls ms/call ms/call name 54.08 1.06 1.06 1259815 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
31.12 1.67 0.61 27939892 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

A sample of untangle, which is almost all black and white:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 61.84 7.34 7.34 165550334 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
35.89 11.60 4.26 2498395 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
% cumulative self self total time seconds seconds calls ms/call ms/call name 78.94 5.51 5.51 3671557 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
16.48 6.66 1.15 240161310 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

I'd also be happy to add these as separate dithering modes (e.g. BAYER_BW_2 or something), in case we want to let users opt in to this behavior. If you were rendering a grayscale bitmap, for instance, this is probably unhelpful, and just adds 2 extra comparisons per pixel.

[raisjn]

this seems reasonable, thanks!

regarding animations and potential slow down, also see ddvk/remarkable2-framebuffer#42. if the rm2fb queue is filled, it will cause delay in painting until the queue settles (this is contrary to how rm1 worked, i believe).

if you turn on DEBUG in the rm2fb client/server code, you can see the update requests and draw timings - an example output can be seen here: ddvk/remarkable2-framebuffer#38 (comment). this will let you get a sense of how much repainting a particular region costs with a particular waveform.

[raisjn]

i just played with the release build with these changes, the performance is good! i had been using the debug build previously, so was very happy to see release build perf - i think it feels pretty snappy for an e-reader

(i also think the rm2fb queue getting filled is not the issue after doing some small testing)

[mrichards42]

Awesome! Yeah, it's pretty decent with a release build. Agreed that I don't think it's an issue w/ the rm2fb queue -- although that might have been part of the trouble I had w/ the dithering demo.

[raisjn]

i'm curious if #78 speeds up drawing at all for you

• uses draw_rect_fast which doesn't call update_dirty (which does a bunch of extra work for each pixel)
• uses likely/unlikely
• split rectangle drawing into separate cases: one case for fill, one for non-fill. non-fill is now O(N+M) instead of (N*M)

i am unsure of how you did your profiling cases above - is it just a single render? (or X renders?) of a game scene? or does it involve manual interaction with the game?

[mrichards42]

I've noticed that some of the remarkable_puzzle animations are super slow, so I've been doing some profiling. draw_rect and whichever dithering function I use together take up about 90% of the time according to gprof, so I'm focusing on those :)

One pretty simple optimization is skipping dithering for WHITE and BLACK colors -- the dithering matrices are normalized so that they add or subtract less than 50% of the difference between two colors (so, e.g. in 2-color dithering 0.0 is shifted to between -0.49 and 0.49, which rounds back to 0.0 in all cases).

This change gives me between a 2x and 5x speedup in dithering, depending on how much gray is being drawn:

A sample of lightup, which uses a lot of gray:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 45.86 1.22 1.22 24576951 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
39.47 2.27 1.05 1253836 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
# after
% cumulative self self total time seconds seconds calls ms/call ms/call name 54.08 1.06 1.06 1259815 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
31.12 1.67 0.61 27939892 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

A sample of untangle, which is almost all black and white:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 61.84 7.34 7.34 165550334 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
35.89 11.60 4.26 2498395 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
% cumulative self self total time seconds seconds calls ms/call ms/call name 78.94 5.51 5.51 3671557 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
16.48 6.66 1.15 240161310 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

I'd also be happy to add these as separate dithering modes (e.g. BAYER_BW_2 or something), in case we want to let users opt in to this behavior. If you were rendering a grayscale bitmap, for instance, this is probably unhelpful, and just adds 2 extra comparisons per pixel.

[raisjn]

this seems reasonable, thanks!

regarding animations and potential slow down, also see ddvk/remarkable2-framebuffer#42. if the rm2fb queue is filled, it will cause delay in painting until the queue settles (this is contrary to how rm1 worked, i believe).

if you turn on DEBUG in the rm2fb client/server code, you can see the update requests and draw timings - an example output can be seen here: ddvk/remarkable2-framebuffer#38 (comment). this will let you get a sense of how much repainting a particular region costs with a particular waveform.

[raisjn]

i just played with the release build with these changes, the performance is good! i had been using the debug build previously, so was very happy to see release build perf - i think it feels pretty snappy for an e-reader

(i also think the rm2fb queue getting filled is not the issue after doing some small testing)

[mrichards42]

Awesome! Yeah, it's pretty decent with a release build. Agreed that I don't think it's an issue w/ the rm2fb queue -- although that might have been part of the trouble I had w/ the dithering demo.

[raisjn]

i'm curious if #78 speeds up drawing at all for you

• uses draw_rect_fast which doesn't call update_dirty (which does a bunch of extra work for each pixel)
• uses likely/unlikely
• split rectangle drawing into separate cases: one case for fill, one for non-fill. non-fill is now O(N+M) instead of (N*M)

i am unsure of how you did your profiling cases above - is it just a single render? (or X renders?) of a game scene? or does it involve manual interaction with the game?

[mrichards42]

I've noticed that some of the remarkable_puzzle animations are super slow, so I've been doing some profiling. draw_rect and whichever dithering function I use together take up about 90% of the time according to gprof, so I'm focusing on those :)

One pretty simple optimization is skipping dithering for WHITE and BLACK colors -- the dithering matrices are normalized so that they add or subtract less than 50% of the difference between two colors (so, e.g. in 2-color dithering 0.0 is shifted to between -0.49 and 0.49, which rounds back to 0.0 in all cases).

This change gives me between a 2x and 5x speedup in dithering, depending on how much gray is being drawn:

A sample of lightup, which uses a lot of gray:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 45.86 1.22 1.22 24576951 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
39.47 2.27 1.05 1253836 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
# after
% cumulative self self total time seconds seconds calls ms/call ms/call name 54.08 1.06 1.06 1259815 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
31.12 1.67 0.61 27939892 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

A sample of untangle, which is almost all black and white:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 61.84 7.34 7.34 165550334 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
35.89 11.60 4.26 2498395 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
% cumulative self self total time seconds seconds calls ms/call ms/call name 78.94 5.51 5.51 3671557 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
16.48 6.66 1.15 240161310 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

I'd also be happy to add these as separate dithering modes (e.g. BAYER_BW_2 or something), in case we want to let users opt in to this behavior. If you were rendering a grayscale bitmap, for instance, this is probably unhelpful, and just adds 2 extra comparisons per pixel.

[raisjn]

this seems reasonable, thanks!

regarding animations and potential slow down, also see ddvk/remarkable2-framebuffer#42. if the rm2fb queue is filled, it will cause delay in painting until the queue settles (this is contrary to how rm1 worked, i believe).

if you turn on DEBUG in the rm2fb client/server code, you can see the update requests and draw timings - an example output can be seen here: ddvk/remarkable2-framebuffer#38 (comment). this will let you get a sense of how much repainting a particular region costs with a particular waveform.

[raisjn]

i just played with the release build with these changes, the performance is good! i had been using the debug build previously, so was very happy to see release build perf - i think it feels pretty snappy for an e-reader

(i also think the rm2fb queue getting filled is not the issue after doing some small testing)

[mrichards42]

Awesome! Yeah, it's pretty decent with a release build. Agreed that I don't think it's an issue w/ the rm2fb queue -- although that might have been part of the trouble I had w/ the dithering demo.

[raisjn]

i'm curious if #78 speeds up drawing at all for you

• uses draw_rect_fast which doesn't call update_dirty (which does a bunch of extra work for each pixel)
• uses likely/unlikely
• split rectangle drawing into separate cases: one case for fill, one for non-fill. non-fill is now O(N+M) instead of (N*M)

i am unsure of how you did your profiling cases above - is it just a single render? (or X renders?) of a game scene? or does it involve manual interaction with the game?

[mrichards42]

I've noticed that some of the remarkable_puzzle animations are super slow, so I've been doing some profiling. draw_rect and whichever dithering function I use together take up about 90% of the time according to gprof, so I'm focusing on those :)

One pretty simple optimization is skipping dithering for WHITE and BLACK colors -- the dithering matrices are normalized so that they add or subtract less than 50% of the difference between two colors (so, e.g. in 2-color dithering 0.0 is shifted to between -0.49 and 0.49, which rounds back to 0.0 in all cases).

This change gives me between a 2x and 5x speedup in dithering, depending on how much gray is being drawn:

A sample of lightup, which uses a lot of gray:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 45.86 1.22 1.22 24576951 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
39.47 2.27 1.05 1253836 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
# after
% cumulative self self total time seconds seconds calls ms/call ms/call name 54.08 1.06 1.06 1259815 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
31.12 1.67 0.61 27939892 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

A sample of untangle, which is almost all black and white:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 61.84 7.34 7.34 165550334 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
35.89 11.60 4.26 2498395 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
% cumulative self self total time seconds seconds calls ms/call ms/call name 78.94 5.51 5.51 3671557 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
16.48 6.66 1.15 240161310 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

I'd also be happy to add these as separate dithering modes (e.g. BAYER_BW_2 or something), in case we want to let users opt in to this behavior. If you were rendering a grayscale bitmap, for instance, this is probably unhelpful, and just adds 2 extra comparisons per pixel.

[raisjn]

this seems reasonable, thanks!

regarding animations and potential slow down, also see ddvk/remarkable2-framebuffer#42. if the rm2fb queue is filled, it will cause delay in painting until the queue settles (this is contrary to how rm1 worked, i believe).

if you turn on DEBUG in the rm2fb client/server code, you can see the update requests and draw timings - an example output can be seen here: ddvk/remarkable2-framebuffer#38 (comment). this will let you get a sense of how much repainting a particular region costs with a particular waveform.

[raisjn]

i just played with the release build with these changes, the performance is good! i had been using the debug build previously, so was very happy to see release build perf - i think it feels pretty snappy for an e-reader

(i also think the rm2fb queue getting filled is not the issue after doing some small testing)

[mrichards42]

Awesome! Yeah, it's pretty decent with a release build. Agreed that I don't think it's an issue w/ the rm2fb queue -- although that might have been part of the trouble I had w/ the dithering demo.

[raisjn]

i'm curious if #78 speeds up drawing at all for you

• uses draw_rect_fast which doesn't call update_dirty (which does a bunch of extra work for each pixel)
• uses likely/unlikely
• split rectangle drawing into separate cases: one case for fill, one for non-fill. non-fill is now O(N+M) instead of (N*M)

i am unsure of how you did your profiling cases above - is it just a single render? (or X renders?) of a game scene? or does it involve manual interaction with the game?

[mrichards42]

I've noticed that some of the remarkable_puzzle animations are super slow, so I've been doing some profiling. draw_rect and whichever dithering function I use together take up about 90% of the time according to gprof, so I'm focusing on those :)

One pretty simple optimization is skipping dithering for WHITE and BLACK colors -- the dithering matrices are normalized so that they add or subtract less than 50% of the difference between two colors (so, e.g. in 2-color dithering 0.0 is shifted to between -0.49 and 0.49, which rounds back to 0.0 in all cases).

This change gives me between a 2x and 5x speedup in dithering, depending on how much gray is being drawn:

A sample of lightup, which uses a lot of gray:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 45.86 1.22 1.22 24576951 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
39.47 2.27 1.05 1253836 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
# after
% cumulative self self total time seconds seconds calls ms/call ms/call name 54.08 1.06 1.06 1259815 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
31.12 1.67 0.61 27939892 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

A sample of untangle, which is almost all black and white:

# before
% cumulative self self total time seconds seconds calls ms/call ms/call name 61.84 7.34 7.34 165550334 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)
35.89 11.60 4.26 2498395 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
% cumulative self self total time seconds seconds calls ms/call ms/call name 78.94 5.51 5.51 3671557 0.00 0.00 framebuffer::FB::draw_rect(int, int, int, int, int, int, float)
16.48 6.66 1.15 240161310 0.00 0.00 framebuffer::DITHER::BAYER_2(int, int, unsigned short)

I'd also be happy to add these as separate dithering modes (e.g. BAYER_BW_2 or something), in case we want to let users opt in to this behavior. If you were rendering a grayscale bitmap, for instance, this is probably unhelpful, and just adds 2 extra comparisons per pixel.

[raisjn]

this seems reasonable, thanks!

regarding animations and potential slow down, also see ddvk/remarkable2-framebuffer#42. if the rm2fb queue is filled, it will cause delay in painting until the queue settles (this is contrary to how rm1 worked, i believe).

if you turn on DEBUG in the rm2fb client/server code, you can see the update requests and draw timings - an example output can be seen here: ddvk/remarkable2-framebuffer#38 (comment). this will let you get a sense of how much repainting a particular region costs with a particular waveform.

[raisjn]

i just played with the release build with these changes, the performance is good! i had been using the debug build previously, so was very happy to see release build perf - i think it feels pretty snappy for an e-reader

(i also think the rm2fb queue getting filled is not the issue after doing some small testing)

[mrichards42]

Awesome! Yeah, it's pretty decent with a release build. Agreed that I don't think it's an issue w/ the rm2fb queue -- although that might have been part of the trouble I had w/ the dithering demo.

[raisjn]

i'm curious if #78 speeds up drawing at all for you

• uses draw_rect_fast which doesn't call update_dirty (which does a bunch of extra work for each pixel)
• uses likely/unlikely
• split rectangle drawing into separate cases: one case for fill, one for non-fill. non-fill is now O(N+M) instead of (N*M)

i am unsure of how you did your profiling cases above - is it just a single render? (or X renders?) of a game scene? or does it involve manual interaction with the game?