You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Good catch! Is this x2 factor an estimate or did you already try?
One thing you may be interested in is BenchmarkRun and BenchmarkPlot in module jzy3d-tests-java9. It evaluates rendering time based on content to render. I used it to show how sensitive EmulGL and jGL are to the number of polygons to render, assuming these polygons (either a single, 10 or 100) always cover the same number of pixels.
Is this x2 factor an estimate or did you already try?
I've tested that on M1 Air with Apple Silicon, went from 120ms to 60ms per frame when I removed switch-case and kept only actual branch
Will try BenchmarkRun for better consistency
You will see that this test only involves black pixel on a flat surface. The idea was mainly to have a guess on sensitivity to number of pixels to paint vs. polygon you’re draw.
It should not be hard to derive it and evaluate blending cost on a colored surface.
One point worth mentioning : EmulGL has an unsatisfying way of handling blending. The less alpha you configure, the darker polygon you have. I’ll send you links about it.
Quality.Intermediate with no alpha has vivid colors
I am willing to understand where this fading effect comes from. Using alpha = 0 creates black pixels instead of background color pixels.
jzy3d
changed the title
Software rendering performance can be significantly improved by optimising blend_pixel
[EmulGL] Software rendering performance can be significantly improved by optimising blend_pixel
May 1, 2022
switch - case
insideblend_pixel
causes almost 2x performance degradation due to mixing of branching and numeric pipelinePipeline flame graph:
As
BlendFunc
rarely changes during polygon rendering, one can try to use lambdas to optimise pixel blending performanceThe text was updated successfully, but these errors were encountered: