Just so you know: Here is my updated list of things for the next release. I wonder if I'm missing anything?
_________
1) stack cookie [FAILED] Not possible to set in shared object. Needs to be set manually on a per application basis.
2) Window alignment at beginning.[OK?] This happens because window sizes are only set at some point _after_ the widget has been created. Apparently it is not possible for intuition to open windows "out of bounds" (for instance (-100, -100, 20, 20)). The next best option is to open a very small window at the top left and let it resize. There is not much more I can do without messing things up real bad. Some dialogs will still "spawn", but really there is not much I can do about it.
3) DesktopServices [EXPERIMENTAL] An experimental version included. Didn't test it, but at least it should get your code compiled.
4) Assign problems [FIXED?] Should be fixed now.
5) Prefs app. Planned![DONE!]
6) Native menus[FIXED]
7) Turn into standard .library. [FAIL] Not going to happen, sorry!
8) uic3. [EXPERIMENTAL] Needs a closer look.
9) Slow startup. Not much I can do here except remove debug output. .so's are slow on Amiga.
10) Double click from system prefs. [FIXED]
11) ASL on public screen. Yeah bummer, I will fix this.[FIXED]
12) Window height limited to 1080. [FIXED]This is a terrible example of bad coding on my behalf. My own screen is 1080 high, so any other screen should be the same... Doh!
13) local keymap. Implemented an env variable to define local keymap codec. [CHECK]
14) GLWidget dependence on custom minigl. [FIXED?] Don't know what to do with this one...
15) Installation script. Planned.
16) Mouse wheel support. Planned [DONE!]
17) Right mouse button (and context menus)? [DONE!]
Well, if you ask :) Did't you want to bother with "fontconfig" stuff ? I mean to make some window about "font generation happens" or kind (just to show users that its only one time, and that need to wait a bit). Of course its better to just avoid fontconfig usage, and use a way like Joerg do with Ra-OWB, but i know how all of this boring and un-interesting to do, but well .. result are good if you will in interest to worry :)
In others, all the other problems about which i can think for now, its just understand why some apps are slow in rendering and some are pretty fast. Like those ones which i port before : hexglass very fast , but colorcode and easypaint very-very slow. Did it all about that "framebuffer objects" , or even maybe not ? And if its about framebuffer objects problems, maybe it possible somehow to disable/redirect/re-code that stuff, to make it works fast ? I know (and understand fully) that you want to wait for Gallium, but as we all know progress-timelines, it can be forced in end to result that we will use cool-good, but very-very slow qt apps for the next years or so :)
Dunno, maybe something like "opengl mode on/off" in prefs ? Or maybe indeed making framebuffer objects in minigl will be a worth of it ? (i as usually can help with all the testing and annoing-motivation :)) )
Related to "amiga-native-theme", i think we can worring with it after all and for the final end, as it pure cosmetic.
ps. btw, amiga+c/amiga+v works for copy+paste text to/from clipboard ?
- Native fonts - Iconify gadget support for all demos (i really hope it will be possible) - An AmigaOS4 like skin (for scrollbars and all the other UI elements)
And then ... well i would like to see the new beta before ask more
What exactly do you mean by "native fonts"? If you mean non-fontconfig graphics.library fonts, then the answer is probably no. This is too much of a hazzle compared to the benefits, I think.
I _can_ do some sort of progress bar to show fontconfig loading. This is actually a good feature request.
Iconify gadget is also a good request.
About speed, this has been discussed before, and the anser is, that because of the lack of features in minigl (eg. frame buffer objects) the current port is slowish. An option could be to try and implement frame buffer objects in minigl, but currently I have no idea how to do that, and so I have no idea how much work is going to be involved.
About native theme, this has also been discussed before, and the answer lies somewhere in the wind, as I have no idea how much work would be involved, and if it is possible at all.
About turning opengl off, this is not going to happen, since the native rendering engine sucks, and I have no intention of improving it (if you want to see for yourself, check out this screenshot). There would be absolutely no benefit of doing such an engine, in fact it is going to be more or less the same as we have now with raster rendering engine (invoked when there is drawing to a pixmap going on).
The clipboard shortcuts are CTLR-c, CTRL-x and CTRL-v.
Maybe it will possible then for the porters to do something with speed ? I mean in the code of ported apps, like change usage of that on that, change that QT fucntion on that, and as result all will be fast ?
From my imho, if one of the apps are very fast (hexgalss), then other one (easypaint) can be fast as well if porter will change something on something.. Just need to know what fucntions change , and on which one. Or maybe somehow change rendering mechanisms in the apps, etc ? Or maybe disable "doubl-buffering" for app ? (let's its all flickers, btu will be fast).
I mean let's be then QT use minigl everythere, just for us (porters) will need some tips how to make all the apps fast and what we can change :)
So, QPixmap its that "framebuffer objects" crap ? I.e. if i just do search on source code of some QT app, and will found "QPixmap" , that mean that app will be slow for now. And if not, then all should be fine in terms of speed, right ?
It is possible at all , just replace QPixmap on something from coder-side ?
Anyway, thanks for input, i will try to do search on QPixmap in hexglass (which are fast) and in the easypaint (which are slow).
The thing that is slow is _only_ rendering into a QPixmap(). That is, if at some point the code uses a QPixmap as paint device eg. if you see something like
QPainter p(pixmap); ... (drawing)
this is going to slow down things. Rendering directly to a QWidget should be fine.
buttonCursor->setIcon(QPixmap(":/gadgets/icons/gadgets/cursor.png")); buttonLastic->setIcon(QPixmap(":/gadgets/icons/gadgets/lastic.png")); .. and so on for all the stuff ..
In other words, in that mainwindow.cpp file, all the QPixmap are used for the load all the png images.
As i undersrand, if it loads one time via QPixmap, then, it will be used by the programm all the time via QPixmap ?
CColorWidget.cpp
There is QPixmap are one time:
Quote:
CColorWidget::CColorWidget(int r, int g, int b/*QObject *parent*/)// : QLabel(parent) { setFrameStyle(QFrame::Raised | QFrame::Box); currentColor = new QColor(r, g, b); pixmapColor = new QPixmap(17, 17); painterColor = new QPainter(pixmapColor); painterColor->fillRect(0, 0, 17, 17, *currentColor); painterColor->end(); setMargin(3); setAlignment(Qt::AlignHCenter); setPixmap(*pixmapColor); }
CImageCV.cpp
Quote:
void CImageCV::setActiveTool(const ETools &tool) { ...balbalbal... case PEN: this->setCursor(QCursor(QPixmap(":/gadgets/icons/gadgets/pencil.png"))); displacePoint = QPoint(-8, 7); break; case LASTIC: this->setCursor(QCursor(QPixmap(":/gadgets/icons/gadgets/lastic.png"))); displacePoint = QPoint(-4, 6); break; case LINE: this->setCursor(QCursor(QPixmap(":/cursors/icons/cursors/cross.png"))); displacePoint = QPoint(-1, -1);
... and so on for everything ....
So as i see, there is also all .png images used by Qtpixmap.
And in the end:
CPaletteWidget.cpp
That one seems create full palette over qpixmap:
Quote:
CPaletteWidget::CPaletteWidget() { palette = new QPixmap(":/program/icons/program/palette.png"); resize(palette->size()); setAlignment(Qt::AlignHCenter); setPixmap(*palette); }
So .. that all. No more QPixmap words in the programm. I think on that simply easy programm will be good to understand how to replace the stuff, and check if its indeed all because of that QPixmap.
Maybe you even have some ideas how replace quoted code ? Looks imho easy, expectually those png images loading should be for sure have different ways of loading , but the same handling as via qpixmap. Have a look at this plz :)
PS. While i read that links which you post, maybe it will be not bad idea for now just in the QT code, put to the QPixmap code from QImage ? Did QImage works fast and with no problems ?
Dunno , but looks like that ColorCode slow not because of QPixmap ? I just feel that there is something else, not only qpixmap problem.. Can you have a look at easypaint or colorcode ?
2) Window alignment at beginning.[OK?] This happens because window sizes are only set at some point _after_ the widget has been created. Apparently it is not possible for intuition to open windows "out of bounds" (for instance (-100, -100, 20, 20)). The next best option is to open a very small window at the top left and let it resize. There is not much more I can do without messing things up real bad. Some dialogs will still "spawn", but really there is not much I can do about it.
Just curiosity, but I wonder why this is a problem on Amiga but not (for example) Windows or Linux?
If window size is not know until some point after the widget has been created, can you not delay opening of the actual Intuition window until the size *is* known? Or is that what would cause the "messing things up real bad"?
Otherwise your progress with Qt sounds really awesome .
What exactly do you mean by "native fonts"? If you mean non-fontconfig graphics.library fonts, then the answer is probably no. This is too much of a hazzle compared to the benefits, I think.
Yes i mean this also because current font are too big :-/
Quote:
The clipboard shortcuts are CTLR-c, CTRL-x and CTRL-v.
Mmm maybe another thing to make it more "Amiga-like" ...
Just curiosity, but I wonder why this is a problem on Amiga but not (for example) Windows or Linux?
Yes I'm wondering about that too. Probably it is because windoze and linux can open windows outside the visible area and later resize/replace them to the visible area.
From the examples you give using QPixmap, it doesn't seem, that that is the cause of the "slowness". You are right, there must be something else to it. I will take a look at the sources one of these days to try and clear up the mysteri. Be patient .
EDIT: Just browsing again I found this:
Quote:
CColorWidget::CColorWidget(int r, int g, int b/*QObject *parent*/)// : QLabel(parent) { setFrameStyle(QFrame::Raised | QFrame::Box); currentColor = new QColor(r, g, b);
pixmapColor = new QPixmap(17, 17); painterColor = new QPainter(pixmapColor);
This is an example of what I mentioned, namely using a QPainter to render into a QPixmap. So this is slow. But on the other hand it seems like just rendering a 17x17 pixmap shouldn't slow everything down so much, so there is definitely something else there as well.
I will take a look at the sources one of these days to try and clear up the mysteri. Be patient :)
Awesome ! Thanks a lot :)
Quote:
This is an example of what I mentioned, namely using a QPainter to render into a QPixmap. So this is slow. But on the other hand it seems like just rendering a 17x17 pixmap shouldn't slow everything down so much, so there is definitely something else there as well.
As i remember, in first versions of QT port, EmbeddedDialogs (for example) was fast. Then, at some point (somethere on 0.4 or 0.5 release), that example start to be on 50-70% slower. Maybe there was introduced something else which use just going to some busyloop ?
I know you know the stuff better, but from all my expirience, i have 100% cpu loading and slownes of everything, when i have for example While() loops without Wait<something>/Delay<microsecond>. In my old warp3d diskmag, i have in the code something like this:
Quote:
while(!esc) {
//fix boosy-loop crap about getmsg/replymsg in loop; WaitPort(window->UserPort);
... some code ... }
Maybe somethere in the port, you introduced some loops, which just slow down everything ?
open windows outside the visible area and later resize/replace them to the visible area
You can open your windows as hidden/invisible with WA_Hidden,TRUE tag (also don't activate it). Then when you know the size of it then use SetWindowAttrs() to unhide it (and activate it and refresh all of its content if necessary as well).
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
.
