GetTextExtent’s underlying platform API is thread safe on Windows, and it probably is as well on X11 since at least xcb and probably also libx11 allows multithreaded access to the server and locks everything as needed. If that’s not the case then it’s easy to fix. The x11 APIs already have a lock, but if it ends up being done on the client then we can call the text sizing APIs like harfbuzz ourselves, and that’s thread safe too. So in the long run it’ll be OK, but not now.
Rendering using the GPU lets the fragment shader compute the actual outline of the font using a special distance map representation, so that’s almost absurdly fast and allows zooming with no CPU involvement.
But that will come later. For now, in a document with many parentheses we size the same parentheses thousands of times, and just avoiding that would help. We need not only a font cache, but also a text size cache - and that will need special effort, since a “simple” string-indexed map or hash will be the maybe last thing we want. But I have something in mind, so that we won’t need to store any string sizes in TextCell, and for that matter we also won’t need to store any strings either.
But more broadly, the improvements we can make probably belong in wxWidgets themselves, and I’ll have to get myself to start pushing some code there.
18 juli 2020 kl. 11:59 fm skrev Gunter Königsman :
The first paragraph more or less describes what we try to do:
First all cells are layouted
If we see that one of these cells is wider than the screen we change it to the linear format that can be broken into lines: For example fractions that normally contain of a numerator and a denominator divided by a horizontal line are converted into the three cells "numerator", "/" and "denominator". The first problem is now that the numerator and denominator inside a 2d fraction are displayed in a smaller font than they are in the linear form. The second problem is that we know that numerator and denominator both might be 2D objects that might be wider than the screen and therefore might need to be converted to linear form, too. And the objects these objects are composed of might still be too wide and therefore might again need to be converted to their linear form before we can introduce the linebreaks.
If we don't recalculate a cell at all that clearly looks like being a bug, though - and I believe that wxMaxima splitting recalculation into recalculating heights and then recalculating widths makes things more complicated [and therefore error-prone] than necessary and at the same time introduces avoidable traversals through lists. Also some cells instead of heights recalculate widths or don't do anything during height calculation and then correct everything during the width calculation => If you haven't starting optimizing this process yet I am willing to try to merge RecalculateHeight and RecalculateWidth of each cell type to a single Recalculate function.
Paralleling things is great. But wxDC::GetTextExtend isn't thread save which means we'd have introduce an awful lot of locking. Also if we want to avoid introducing more threads than we have CPUs at hand if we drop OpenMP we'd have to set up our own task queue management and be careful that this doesn't introduce more overhead than it reduces the calculation time.
But I agree with you: As soon as all relevant compiler versions support instantiating tasks without having to resort to OpenMP we should drop OpenMP.
Parallelizing the output would be fast - and I don't know how much work one could delegate to the GPU, if one starts to optimize the output. But once we stop using only standard wxWidgets methods the standard way it is us who have to manually support all versions of all operating systems including things like an ubuntu version shipping a broken gnome2, a debian version insisting of shipping an old wxWidgets with experimental gnome3 support while entirely dropping gnome2, a nearly-linux compatible OpenBSD, Wayland, X11, perhaps even MIR and a quirky xvfb. We can do many wonders in places that provide a better improvement in performance per working hour we need to invest.
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.