I dunno. Only found out because Qt's default font was set randomly to Helvetica 17 (which doesn't exist, and strangely it looks as if it scales UP from 15 instead of down from 18...).
kas1e wrote: @Elwood hieronymus is buggy. Its totally lockup the pegasos2 when you tryint to use it. I do not remember, but it works only on some kind of machines (or only on a1, or only on sams). I write to author about some time ago, but in latest SDK hieronymus is still lockup peg2.
Hieronymus only works on AmigaOne at the moment. The bug is in the OS unfortunately. Maybe I have an idea to run it on Sam440 but I haven't tried.
I am sure that with tools like that but more advanced, we could find pitfalls in our programs.
Quote:
@alfkil About what i thnik lately, its about somekind of addon/plugin for Valgrind (linux), so we can somehow profiling amigaos4 bins on the linux. As our binary format already "elf" , it can be easy to add some necessary code to valgrind to have support.
Of course we can't use all the valgrind tools, and we even can't load (i think) amigaos4 binary to it to have ability to use all the valgrind parts, but for sure we can reuse some profiling parts. Have you interest to have a look at this ? At least we have cross-compilers, so all is here already ..
afxgroup wrote: As i told you on skype there is a QT implementation that doesn't redraw the entire image every time but only the damaged zones. And actually our implementation use the first method. It is possible that the second implementation will speed up a lot the whole draw process
I thought that this was the default way how Qt handles the drawing? While developing a Qt application for N900 I noticed that paintEvent is called only when the area needs to be redrawn, for ex. when the content changes or something is overlapping etc...
It IS the default method. But I'm not sure wether it works as it should or not. Especially because of the rendering problem in QScintilla. So it is on my todo list to find out how it actually works.
Hieronymus only works on AmigaOne at the moment. The bug is in the OS unfortunately.
Are you sure? I though the problem was due to Hieronymus using a feature unsupported by the Sam440's CPU?
I am sure: a bug was filled in the OS4 tracker.
There is a feature that is not supported by the 440 core : it has no performance monitor. But it is not used in Hieronymus to profile but only to give the number of cache misses, as a bonus.
broadblues : If have not tried gprof on Amiga because I think with this kind of approach, it may be intrusive, it is necessary to recompile and it can't profile dynamic libraries.
News: Not exactly about text speed, but I have implemented texture drawing using graphics.library CompositeTags, and it seems to be faster than miniGL rendering . New release comming soon!
Depending on how much work I put into it, some features are just too hard to implement using only graphics.library and nothing else. I'm thinking of rotating of text (could maybe be done with CompositTags...), pen styles, that are not solid and not 1 pixel wide, acurate rendering of texture brushes etx etc. Again time is the most crucial resource here, and also feasability, because eventually we will have MESA, and all this work will be redundant (more or less).
alfkil wrote: Depending on how much work I put into it, some features are just too hard to implement using only graphics.library and nothing else. I'm thinking of rotating of text (could maybe be done with CompositTags...)
Yes, CompositeTags can do 3D vector rotations, so a simple rotation of text should be possible. I don't understand vector rotation at all, so don't ask me how to do it!
Scaling and alpha blits through CompositeTags are far faster than through BitMapScale and BltBitMapTags.
Quote:
, pen styles, that are not solid and not 1 pixel wide, acurate rendering of texture brushes etx etc.
I had similar issues with NetSurf's graphics.library plotter - it doesn't support arcs, bezier curves, different line widths etc. Also you don't get anti-aliasing for free when drawing curves with graphics.library. It is better to use Cairo for drawing, unless you need clipping, which seems to be quite slow still (but far far faster than in earlier versions of Cairo; I'd rather attach Cairo to a RastPort and do clipping through that, shame this isn't possible as that should resolve the performance issue).
If you are line drawing with graphics.library you might want to look at Cairo if Qt doesn't do heavy amounts of clipping (NetSurf does clip-draw-clip-draw-clip-draw which really slows it down, so I took out Cairo clipping, only graphics.library parts get clipped , but this doesn't make any real world difference visually)
Just for now, maybe you can tell me how to attach a cairo context to a RastPort?? I can only find cairo_amigaos_surface_create, which attaches directly to the BitMap, which is not so useful with windows. Of course I can render into memory and then blit, but eh...
Also did someone post an updated doc for CompositeTags()?? I don't think the one from the SDK has everything in it...
EDIT: On a related note, maybe someone here can help with this
Just for now, maybe you can tell me how to attach a cairo context to a RastPort?? I can only find cairo_amigaos_surface_create, which attaches directly to the BitMap, which is not so useful with windows. Of course I can render into memory and then blit, but eh...
You can't, hence my comment:
Quote:
I'd rather attach Cairo to a RastPort and do clipping through that, shame this isn't possible as that should resolve the performance issue
You have to attach it to a BitMap (which has to be ARGB32) then blit that to the window, which is what I thought you were doing anyway? It's usually easier as you only need to take the window border etc into account at the point you blit, rather than for every operation.