Bug 1826134 Comment 1 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Seems like a far bigger issue in that profile is the constant memcpy and RawTexImage calls, with glBufferSubData not really being much of a factor by comparison. It is bypassing the Stroke fast-path entire, most likely because it's supplying options that AA-Stroke can't support (usually some form of alpha transparency, since AA-Stroke requires full opacity).
Seems like a far bigger issue in that profile is the constant memcpy and RawTexImage calls, with glBufferSubData not really being much of a factor by comparison. It is bypassing the Stroke fast-path entire, most likely because it's supplying options that AA-Stroke can't support (usually some form of alpha transparency, since AA-Stroke requires full opacity).

Also the biggest overhead here is still SendGetFrontBuffer waiting for all this GPU work to complete, which means we're still blocked partially on Sotaro's work on fixing up async-present to work around that overhead.
Seems like a far bigger issue in that profile is the constant memcpy and RawTexImage calls, with glBufferSubData's contribution maybe being somewhat questionable by comparison? For some reason we're doing a lot of regenerating the clip mask, which ideally we reeeeally don't want to happen a lot. Maybe that aspect is fixable and can make performance here tolerable without any extensive overhaul of the VBO setup otherwise.

Also the biggest overhead here is still SendGetFrontBuffer waiting for all this GPU work to complete, which means we're still blocked partially on Sotaro's work on fixing up async-present to work around that overhead.

Back to Bug 1826134 Comment 1