caskbench text test case in lags heavily in skia

[chevalam]

Output in cairo and skia text test case match correctly but skia-text test case is lags when compared to cairo text

[chevalam]

Hi Henry ,

I had worked on skia-text test case and had raised issue in github for the same. Below is the call flow for drawText.
drawText() - > GrBitmapTextContext::drawText() -> drawPackedGlyph() -> drawPath().

In the above call flow , there are two stages where finish()/flush() is invoked , one in drawPackedGlyph () and one in drawText() after drawPackedGlyph().
I have commented the finish()/flush() in drawPackedGlyph() and the output for text test case is same but the benchmark numbers are better .
Would it be acceptable if we can get rid of the flush in drawPackedGlyph since there is one flush in drawText after drawPackedGlyph.

Below are the readings captured on PC and device with and without modifications.

---

PC/mesa 10.0 :
On commenting flush:
cairo-text 64 PASS 10 0.035369 0.081840
skia-text 64 PASS 10 0.940362 0.960749 -1073.94%

Current:
cairo-text 64 PASS 10 0.036002 0.083150
skia-text 64 PASS 10 1.542647 1.588705 -1810.65%

Below is the commented flush from GrBitmapTextContext.cpp
@@ -531,8 +531,8 @@ void GrBitmapTextContext::drawPackedGlyph(GrGlyph::PackedID packed,
}

•    this->flushGlyphs();
  

•    fContext->flush();
  

• // this->flushGlyphs();
• // fContext->flush();

Call control goes from drawPackedGlyph() to drawPath where path is drawn into stencil buffer.

Regards,
Srikanth.

[chevalam]

Hi Henry ,

I have found two cases for the drawText scenario :

1.LCD Rendering - setLCDRendering(true) : ‘drawText’ takes 830 µs, the ‘drawPackedGlyph’ takes around 50 µs and there is a while loop across drawPackedGlyph i.e, ‘while(text <stop) { drawPackedGlyph() }’ which takes 812 µs.
On profiling drawPackedGlyph() , there is a time taking ‘GrTextStrike::addGlyphToAtlas()’ which invokes ‘SkGrFontScaler::getPackedGlyphImage()’ (~30µs) and ‘GrAtlasMgr::addToAtlas()(~20µs)’ .

Below Is the equation to sum the profiling breakup :
drawText - 830 µs = while{ drawPackedGlyph () [50 µs] } - 812 µs drawPackedGlyph () [50 µs] = getPackedGlyphImage() [30 µs]+ GrAtlasMgr::addToAtlas() [20 µs]

I am currently working to verify if either of the time consuming areas i.e., the while loop , getPackedGlyphImage or addToAtlas can be optimized .

1. Default Rendering :
   drawText is redirected to drawPath via drawPackedGlyph in default rendering scenario .
   But the issue I observed here is that unlike in LCD Rendering , a flush() is called for every drawPackedGlyph () . So if the while across drawPackedGlyph loops for 10 times , flush is called 10 times .
   This seems to be an issue that might be optimized . I am currently checking on why the flush is invoked so frequently in the case of default rendering which might help rendering times.

Regards,
Srikanth.

[chevalam]

Hi Henry ,

Follow up on drawText observations :

a) Default Rendering :
drawPath is used to handle default rendering scenario . The path followed for LCD Rendering i.e., addToAtlas , getGlyphMatrics is also traversed for default rendering. But textures won’t be used for default rendering scenario , fplot is returned NULL and addToAtlas() , freeUnusedPlot() routines need not be invoked for default rendering scenario . Below are the readings captured with and without the texture code for default rendering.

Below are the readings before and after modifications. It is observed that there is an improvement in skia readings.

Before:
cairo-text 100 PASS 100 5
skia-text 100 PASS 100 0 -1094.91%

After:
cairo-text 100 PASS 100 5
skia-text 100 PASS 100 1 -491.86%

I am trying to find out the flag to differentiate between default rendering and lcd rendering handling. Kindly let me know if the approach is acceptable . Below is the patch for the same:

---

diff --git a/src/gpu/GrBitmapTextContext.cpp b/src/gpu/GrBitmapTextContext.cpp index 3b5e27a..a1e18c4 100755
--- a/src/gpu/GrBitmapTextContext.cpp
+++ b/src/gpu/GrBitmapTextContext.cpp
@@ -514,6 +514,8 @@ void GrBitmapTextContext::drawPackedGlyph(GrGlyph::PackedID packed,
}

 if (NULL == glyph->fPlot) {

• if (fSkPaint.isLCDRenderText()) 
  

•   {
   if (fStrike->addGlyphToAtlas(glyph, scaler)) {
       goto HAS_ATLAS;
   }
  

  @@ -539,7 +541,7 @@ void GrBitmapTextContext::drawPackedGlyph(GrGlyph::PackedID packed,
  fStrike->addGlyphToAtlas(glyph, scaler)) {
  goto HAS_ATLAS;
  }

•   }
   if (NULL == glyph->fPath) {
       SkPath\* path = SkNEW(SkPath);
       if (!scaler->getGlyphPath(glyph->glyphID(), path)) {
  

---

b) LCD Rendering :
drawText executes drawPackedGlyph in a while loop . Each drawPackedGlyph() invokes two routines which majorly contribute to the time taken by drawText.
getGlyphMatrics – retrives glyph through hash table retrieval of glyphID and copies the glyph data into image buffer addToAtlas – Invokes BindTexture,glTexSubImage2D and copies uses image buffer for the texture It would help if the while loop could be replaced by a single call instead of multiple drawPackedGlyph calls which invoke 1 and 2 .

Regards,
Srikanth.

[chevalam]

Hi Henry ,

In continuation of the earlier analysis of drawText , I have observed that there are other drawText() APIs like drawTextOnPath(), drawTextOnPos() which also call render/call drawPath() letter by letter in a while loop .

In the case of drawText() , SkUTF8_NextUnichar() retrieves hash ID for each glyph on which drawPath() is called . This is repeated for all the letters passed on to drawText.

Would it help if we can add all the letters to the path and call drawPath only once instead of multiple drawPaths ?

I am trying to check as to how the text scenario is being handled cairo ?

Regards,
Srikanth.

---

Hi Henry ,
LCD Rendering - setLCDRenderText(true) is invoked before drawText() is called. Texture rendering is used to draw the text onto the screen in this scenario .
Default Rendering - drawText() is used to render text onto screen . drawText is redirected to drawPath via drawPackedGlyph in this scenario .

In both the cases i.e, texture rendering / drawPath , it seems that the rendering is being done letter by letter . I am currently checking if this can be improved .

Regards,
Srikanth.

---

Hi, Srikanth

I don't have enough knowledge on difference of LCDrendering and default rendering in skia. What is the difference?

Thanks
Henry

[henrysong]

Hi, Srikanth

First We need to understand difference of LCDrendering vs. default text rendering.

Second, we need to know which one is used by Chromium

Third, it is not important drawPath() is called for each glyph. It is important whether each drawPath results in a recordDraw() or all drawPath() are batched. If each drawPath() results in a recordDraw(), then it will be slow, but if drawPath() does not results in a recordDraw() then it means draw text are batched. According to flashcanvas.net test, chromium draw text is faster than cairo. In cairo, draw texts are batched.

Thanks

Henry

---

From: Srikanth Chevalam [notifications@github.com]
Sent: Tuesday, June 10, 2014 11:01 PM
To: Samsung/skia
Subject: Re: [skia] caskbench text test case in lags heavily in skia (#8)

Hi Henry ,

In continuation of the earlier analysis of drawText , I have observed that there are other drawText() APIs like drawTextOnPath(), drawTextOnPos() which also call render/call drawPath() letter by letter in a while loop .

In the case of drawText() , SkUTF8_NextUnichar() retrieves hash ID for each glyph on which drawPath() is called . This is repeated for all the letters passed on to drawText.

Would it help if we can add all the letters to the path and call drawPath only once instead of multiple drawPaths ?

I am trying to check as to how the text scenario is being handled cairo ?

Regards,
Srikanth.

---

Hi Henry ,
LCD Rendering - setLCDRenderText(true) is invoked before drawText() is called. Texture rendering is used to draw the text onto the screen in this scenario .
Default Rendering - drawText() is used to render text onto screen . drawText is redirected to drawPath via drawPackedGlyph in this scenario .

In both the cases i.e, texture rendering / drawPath , it seems that the rendering is being done letter by letter . I am currently checking if this can be improved .

Regards,
Srikanth.

---

Hi, Srikanth

I don't have enough knowledge on difference of LCDrendering and default rendering in skia. What is the difference?

Thanks
Henry

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-45704962.

[chevalam]

Hi Henry ,

Thank you for your comments. Some findings based on your inputs.
1)Chromium uses LCDRendering as default since SkiaTextRenderer() of render_text.cc has paint_.setLCDRenderText(true);
2) It is observed that each drawPath() results in a recordDraw() . So drawPath() doesnot seem to be batched.
3)LCDRendering uses BindTexture & glTexSubImage2D and copies using image buffer for texture . Default rendering uses drawPath to draw text .

Regards,
Srikanth

[chevalam]

Hi Henry ,

I have ported and executed text test case of flashcanvas.net on linux and observed that skia text (30fps)is slower than cairo text (60fps) . I guess the chromium flashcanvas.net might be running on skia image backend

Regards,
Srikanth.

[chevalam]

Hi Henry,

Some more observations on the skia drawText performance analysis:
LCD Rendering :

1. When a random color is used in caskbench text case, skia lags when compared to cairo . Reason is that the number of glyph cache misses is more and all the glyphs are created newly and inserted in fcache.
2. When a fixed color is used in caskbench text case , no lag is observed in skia compared to cairo . Reason is that number of glyph cache hits is more and all the glyphs are retrieved from fcache.

Default Rendering.

1. Glyph Cache search always misses and there is no effect of random or fixed color on skia's performance . We are currently debugging as to why glyphs are not found cache even for fixed color.

Regards,
Srikanth.

[chevalam]

Hi Henry ,

Please find some clarifications on the earlier findings on drawText rendering
Why Default Rendering for drawText goes via drawPath -
fTextureRedSupport is set to TRUE in skia because of which TexImage2D is attempted with internalFormat=GL_RED . TexImage2D fails for GL_RED , texture is not created and rendering is completed with drawPath and is very slow when compared to cairo.

For testing purpose , I have manually set fTextureRedSupport to FALSE in GrGLCaps.cpp . This sets internalFormat=GL_ALPHA , TexImage2D passes for GL_ALPHA and texture is created and performance of skia text case for default rendering is now on par with cairo draw Text.

Below are the readings
fTextureRedSupport = 1(Default)
./src/caskbench -t egl text
cairo-text 100 PASS 100 9
skia-text 100 PASS 100 0 -2332.24%

fTextureRedSupport = 0(Modified)
./src/caskbench -t egl text
cairo-text 100 PASS 100 9
skia-text 100 PASS 100 10 3.63%

Could you kindly give your inputs on how to go about the above scenario.

Regards,
Srikanth.

[henrysong]

Hi, Srikanth

That is good finding. I have not looked into text rendering part yet. I would like to know

1. What is chromium using - LCD rendering or default rendering
2. Why is skia using GL_RED?

Thanks

Henry

---

From: Srikanth Chevalam [notifications@github.com]
Sent: Thursday, June 26, 2014 5:07 AM
To: Samsung/skia
Cc: Henry (Yu) Song - SISA
Subject: Re: [skia] caskbench text test case in lags heavily in skia (#8)

Hi Henry ,

Please find some clarifications on the earlier findings on drawText rendering
Why Default Rendering for drawText goes via drawPath -
fTextureRedSupport is set to TRUE in skia because of which TexImage2D is attempted with internalFormat=GL_RED . TexImage2D fails for GL_RED , texture is not created and rendering is completed with drawPath and is very slow when compared to cairo.

For testing purpose , I have manually set fTextureRedSupport to FALSE in GrGLCaps.cpp . This sets internalFormat=GL_ALPHA , TexImage2D passes for GL_ALPHA and texture is created and performance of skia text case for default rendering is now on par with cairo draw Text.

Below are the readings
fTextureRedSupport = 1(Default)
./src/caskbench -t egl text
cairo-text 100 PASS 100 9
skia-text 100 PASS 100 0 -2332.24%

fTextureRedSupport = 0(Modified)
./src/caskbench -t egl text
cairo-text 100 PASS 100 9
skia-text 100 PASS 100 10 3.63%

Could you kindly give your inputs on how to go about the above scenario.

Regards,
Srikanth.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-47217629.

[elima]

1. When a random color is used in caskbench text case, skia lags when compared to cairo . Reason is that the number of glyph cache misses is more and all the glyphs are created newly and inserted in fcache.
2. When a fixed color is used in caskbench text case , no lag is observed in skia compared to cairo . Reason is that number of glyph cache hits is more and all the glyphs are retrieved from fcache.

I wonder if an earlier problem is that cached glyphs have the color attached. I thought it was just alpha level since that's what FreeType2 gives in normal rendering. Shouldn't color be passed separately and multiplied with the alpha from the glyph's tex cache?

[henrysong]

Right, in cairo, only glyphs are cached in alpha-only texture. I don't see any reason to attach color.
I would imagine skia should do the same.

Thanks

Henry

---

From: Eduardo Lima Mitev [notifications@github.com]
Sent: Thursday, June 26, 2014 8:20 AM
To: Samsung/skia
Cc: Henry (Yu) Song - SISA
Subject: Re: [skia] caskbench text test case in lags heavily in skia (#8)

1. When a random color is used in caskbench text case, skia lags when compared to cairo . Reason is that the number of glyph cache misses is more and all the glyphs are created newly and inserted in fcache.
2. When a fixed color is used in caskbench text case , no lag is observed in skia compared to cairo . Reason is that number of glyph cache hits is more and all the glyphs are retrieved from fcache.

I wonder if an earlier problem is that cached glyphs have the color attached. I thought it was just alpha level since that's what FreeType2 gives in normal rendering. Shouldn't color be passed separately and multiplied with the alpha from the glyph's tex cache?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-47239439.

[chevalam]

Hi Henry,

1. What is chromium using - LCD rendering or default rendering
2. Why is skia using GL_RED?

1.Chromium is using LCD Rendering . Reference src/ui/gfx/render_text.cc where setLCDRenderText is set to true by default.
2. skia uses GL_RED if GL version > 3.0 or if GL_EXT_texture_rg otherwise GL_ALPHA is used for teximage2d.

Regards,
Srikanth.

[chevalam]

Hi Henry ,

Right, in cairo, only glyphs are cached in alpha-only texture. I don't see any reason to attach color.
I would imagine skia should do the same.

Some observations on LCD Rendering performance lag in drawText :
There is a setLuminanceColor(computeLuminanceColor(paint)); in skia paint where font color is being used used in cache handling . Disabling this routine or using setLuminanceColor(0) prevents color from being used in cache and skia readings are on par with cairo .

Current reading:
cairo-text 100 PASS 100 383
skia-text 100 PASS 100 31 -1142.23%

Modified reading after disabling setLuminanceColor /setLuminanceColor(0) :
cairo-text 100 PASS 100 390
skia-text 100 PASS 100 419 6.99%

We are currently investigating on the effects of setLuminanceColor(0) on SkPaint.

It is also observed that setLuminanceColor(0) gives good performance on skia image backend for drawText case

Regards,
Srikanth