Conversation
They were originally at: include/utils/SkTextOnPath.h src/utils/SkTextOnPath.cpp From 0fdc53f9ffc6c8a25d551fb49de6f77f2a2fb5e6 Mon Sep 17 00:00:00 2001 From: Mike Reed <[email protected]> Date: Mon, 27 Aug 2018 13:00:37 -0400 Subject: [PATCH] textonpath util Bug: skia:7554 Change-Id: Ifff3030f9d7be24146b5230bbf0e47f73000adfd Reviewed-on: https://skia-review.googlesource.com/141460 Commit-Queue: Mike Reed <[email protected]> Reviewed-by: Mike Reed <[email protected]>
From 1eb9af90291ea09dd1fa16af9fbba71c666c95ad Mon Sep 17 00:00:00 2001 From: Mike Reed <[email protected]> Date: Mon, 1 Oct 2018 12:16:59 -0400 Subject: [PATCH] delete textonpath code -- not used anywhere Bug: skia: Change-Id: Ib645f7c140f87123429170a0bf6f7ed86ce53b3f Reviewed-on: https://skia-review.googlesource.com/158224 Reviewed-by: Florin Malita <[email protected]> Commit-Queue: Mike Reed <[email protected]>
- SkPaint no longer containing anything to do with fonts; passing extra SkFont argument in. (and all those "paint.getTextAlign()" related code is gone) - SkTextToPathIter is also gone around ~m76 - it used the old SkPaint's font to work out glyphs and advances anyway, so this part is new, using SkFont.textToGlyphs() and SkFont.getWidths(). - SkFont.getPath() has different calling conventions from SkTextToPathIter.next()
Adjust prototype The main part of fixing skia-python#326
|
@kyamagu this is mainly upstream code adjusted to work with current - the main adjustment is at 0c8b6b4 . I have very little doubt that the original code works, so it is probably a mistake of mine - the testing code is at https://github.com/HinTak/skia-python-examples/blob/main/draw_text_on_path.py . I am finding that once in a while it does not draw anything, or rather, a very thin line at the very beginning of where the text should be. It happens once in a while, have not seem it in the equivalent c code; but since almost all of this is on the c side, it is likely because i don't understand how skia does delayed drawings. The |
Fixes building on window 2022 with MSVC++ 14
|
Right, this spurious bug seems to be about the timing of the actual rendering. Is this happening in a specific platform/runtime? |
|
It is not limited to cpu canvas (dumping to png) - happens to gpu canvas too. draw_text_on_path does it on a cpu raster. The GTK4_superadvancedGL sample does it on a GPU canvas. Other path drawing are not affected, so the problem seems to be somewhat internal to this c++ code. Maybe I should look at why upstream add |
|
It is on fedora 42, my desktop. |
|
If it is happening in the Python environment, I would suspect that a certain C++ struct that should persist on rendering disappears when the context is turned back to Python. The |
|
@kyamagu thanks for the suggestion. The Hopefully one of them should work |
|
I like the look of the Google code much better - as I said, the AI code looks like it has things inlined, so it is a lot longer with multiple sections which look very similar. (And one does not know the difference between those similar sections). The AI code probably comes from skiasharp somehow. |
|
@kyamagu thanks for the time - it is a simple stupid mistake: an uninitialized variable which is zero in c but gets a random value when inside skia-python. Both valgrind & the compiler (with |
Upstream removed it around m70, but SkiaSharp decided to add their own implementation back. Found this out asking copilot to port the sdl2 example code to gtk4 . It volunteered to give me more interesting demo on skia drawing onto opengl, and somehow it assumes that skia-python has the same api as skia m6X, or skiasharp.
Fixes #326