amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > AROS und Amiga-Emulatoren > AROS, doch noch so instabil ?! [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 -3- [ - Beitrag schreiben - ]

30.04.2013, 10:36 Uhr

OlafSch
Posts: 91
Nutzer
@wawa:

http://www.amigacoding.de/index.php?topic=309.msg1091;topicseen#msg1091

[ - Antworten - Zitieren - Direktlink - ]

30.04.2013, 10:49 Uhr

wawa
Posts: 314
Nutzer
wanderer:
von magorium via amiga-coding.de (der link oben von olaf)
A little research shows why:
hint:http://repo.or.cz/w/AROS.git/blob?f=workbench/classes/datatypes/picture/README
and details:
http://repo.or.cz/w/AROS.git/blob?f=workbench/classes/datatypes/picture/TODO
Zitat:
PDTM_READPIXELARRAY mostly done
PDTA_DestMode (ISG) OK, but ignored internally


... so es sieht so aus als ob das ein job für das aros team wäre. ich sprech mal jetzt deadwood darauf an.

[ - Antworten - Zitieren - Direktlink - ]

30.04.2013, 12:00 Uhr

wawa
Posts: 314
Nutzer
@Georg:
Zitat:
Also ich hab' das hier (ABI V0) getestet und sowohl BltBitMapRastPort() als auch ClipBlit() funktionieren in GM_RENDER.
warum testest du mit v0? es besteht glaube ich keine gerantie dass es auch unter v1 richtig arbeitet. aros68k ist v1!

[ - Antworten - Zitieren - Direktlink - ]

30.04.2013, 19:19 Uhr

wawa
Posts: 314
Nutzer
@georg, jolo:
ich weiss nicht ob da placebo ist, aber der heutige nightly scheint schneller und weniger anfällig auf meinem a4k. ich sehe paar commits von neil hier:
14 hours ago neil Made pointer data arguments of SetPointer() and MakePoi... master commit | commitdiff | tree | snapshot (tar.gz zip)
14 hours ago neil Reverted work-around for ClickToFront-related lock... commit | commitdiff | tree | snapshot (tar.gz zip)
14 hours ago neil Replaced short macro that was only used in one place... commit | commitdiff | tree | snapshot (tar.gz zip)
14 hours ago neil Removed obsolete source file. commit | commitdiff | tree | snapshot (tar.gz zip)
15 hours ago neil Added an empty BeginRefresh()/EndRefresh() pair, to... commit | commitdiff | tree | snapshot (tar.gz zip)



[ - Antworten - Zitieren - Direktlink - ]

01.05.2013, 10:16 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Placebo.
--
--
Author of
NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

[ - Antworten - Zitieren - Direktlink - ]

01.05.2013, 18:31 Uhr

wawa
Posts: 314
Nutzer
@Der_Wanderer:
Zitat:
Placebo.
möglich, ich müsste scalos mal anschmeissen da war es vorhin extrem zu beobachten. ohne systetischen testcase ist schwierig es zu beurteilen da die auswirkung recht random ist, aber ich hatte schon mehr mühe den system gestern in die knie zu bekommen, auch blitten der ganzen flächen ging schneller ls gewohnt imho (aufbau der seiten in aweb). unter uae ist das schwierig zu bemerken, auch ohne jit und mit rtg speicher beinahe auf minimum gesetzt.

[ Dieser Beitrag wurde von wawa am 01.05.2013 um 18:33 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

02.05.2013, 09:00 Uhr

Georg
Posts: 107
Nutzer
Zitat:
Original von wawa:

system gestern in die knie zu bekommen


Hast du mal versucht (davor oder danach) sys:tools/debug/sashimi nebenher laufen zu lassen. Wenn da irgendwas einen Haufen Debug Output warum auch immer macht und es hängt nichts am seriellen Port (oder es läuft kein Tool wie Sashmi das den Output abfängt) könnte das evtl. das System stark ausbremsen.



[ - Antworten - Zitieren - Direktlink - ]

02.05.2013, 11:09 Uhr

wawa
Posts: 314
Nutzer
@Georg:
ich hab serial debug meistens an. nichts bemerkt.

[ - Antworten - Zitieren - Direktlink - ]

02.05.2013, 16:37 Uhr

Georg
Posts: 107
Nutzer
Stabilität von aros-68k: ich hab' das vorhier nie benutzt, gestern aber mal ne Nightly Build mit FS-UAE unter Linux probiert. Mir ist aufgefallen, daß das "screenmode" Prefs Programm recht absturzfreudig war. Ich hab' dann gesehen, daß der Stack in der Shell nur 16 KByte groß war. Das könnte zu wenig sein. Ich hab' dann unter AROS x86 hosted gesehen (AROS mit "debug=stacksnoop" starten und dann in ner AROS Shell C:StackSnoop aufrufen), daß das wohl zu wenig sein könnte. Nach dem Start von "screenmode" war der Stack Usage etwa 14 KByte, und nach dem Selektieren einiger Screenmodes etwa 19 KByte. Unter aros-68k wird es vermutlich so ählich sein (ich' glaub' die stacksnoop Geschichte funktioniert dort wohl noch nicht).

Versucht deshalb vielleicht mal "StackAttack" (mit minstack so um die 40 KByte) vom Aminet früh in der Startup-Sequence zu starten. Das müßte eigentlich auch unter AROS funktionieren.


[ - Antworten - Zitieren - Direktlink - ]

02.05.2013, 18:03 Uhr

wawa
Posts: 314
Nutzer
@Georg:
die stack probleme sind bekannt, screenmode prefs ist einer der betroffenen programe. man könnte es tatsächlich mit stackattack lösen, danke für den tip, ich habe es bisher immer per hand gamacht, in erwartung dass da mal seitens aros tema lösung gefunden wird. reported habe ich das füher schon ein paar mal, aber irgendwann habe ichs gelassen.

edit: auf meine beurteilung der stabilität hat es aber keinen einfluss denn entweder weiss ich dass ein program mit dem zugewisenen stack auskommt, oder erhohe ich das und zwar nicht zu knapp, oder aber wenn was abkratzt gehe ich immer zuerst davon dass stack zu niedrig war.

[ Dieser Beitrag wurde von wawa am 02.05.2013 um 18:06 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

02.05.2013, 18:55 Uhr

Georg
Posts: 107
Nutzer
Zitat:
Original von wawa:

entweder weiss ich dass ein program mit dem zugewisenen stack auskommt, oder erhohe ich das und zwar nicht zu knapp, oder aber wenn was abkratzt gehe ich immer zuerst davon dass stack zu niedrig war.


Ich glaub' nicht daß man so einfach (ohne Tools oder so) wissen kann ob ein Programm mit dem Stack auskommt oder nicht. Mit dem Stack ist das so ne Sache ... ein Programm könnte nen (evtl. viel) zu kleinen Stack haben und dennoch überhaupt nicht instabil sein. Es kann aber zufällige andere Programme/Tasks instabil machen.




[ - Antworten - Zitieren - Direktlink - ]

03.05.2013, 00:19 Uhr

wawa
Posts: 314
Nutzer
@Georg:
wenn eis programm abstürzt gebe ich ihm beim nächsten mal gleich unmöglich viel stack um sicherzugehen. das wäre auch mit stackattack sonst n problem oder?

edit: falls du ne lösung für siehst bitte in aros zu implementieren. ich warte sanlichst darauf damit nicht fummeln zu muessen.

[ Dieser Beitrag wurde von wawa am 03.05.2013 um 00:21 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

03.05.2013, 20:28 Uhr

jolo
Posts: 110
Nutzer
Zitat:
wawa:
kann man aros mit vbcc erwartungsgemäss wirklich bauen?


Im Moment, nein. Ich verwende selber für AROS x86 den 'gcc' Compiler, weiß aber, dass Frank Wille einen 'vbcc'-AROS x86 Compiler in petto hat, welcher aber noch experimentell ist. Ich habe diesen zwar auch installiert, bei mir harmoniert dieser aber nicht mit dem AROS-SDK. Ich habe zwar etliche Header-Dateien aus dem AROS-SDK für den 'vbcc'-Compiler gefixt (auch auf Assembler-Ebene), aber es ist ein unendliches Unterfangen, so dass ich irgendwann das Handtuch geworfen habe.


Zitat:
Georg:
Hängt das jedesmal wenn ClipBlit oder BltBitMapRastPort() in GM_RENDER benutzt wird, oder nur in best. Situationen (z. B. Fenster Vergrößern oder Verschieben wenn es ein SIMPLE REFRESH Fenster ist)? btw: innerhalb eines BeginRefresh()/EndRefresh() keine Funktionen benutzen die direkt/indirekt Gadget Rendern auslösen können!


Schon beim ersten Aufstarten des betreffenden Programmes hängt Intuition. Und ja, es ist ein SIMPLE_REFRESH Fenster. Und nein, innerhalb von BeginRefresh()/EndRefresh() wird rein gar nichts am Display geändert. Siehe Code:

code:
if (iclass == IDCMP_SIZEVERIFY)
{
    if (GadgetsAccessible)
    {
        /* Unlink the gadgets from the window */
        UncoupleGadgets( win, glist, &gmask);
        GadgetsAccessible = 0;
    }

    if (msg)
        ReplyMsg( (struct Message *) msg);

    msg = NULL;     /* Wait till an event occurs */
    while ( !msg)
    {
        WaitPort( win->UserPort);
        msg = (struct IntuiMessage *) GetMsg( win->UserPort);
    }
    iclass = msg->Class;
    icode = msg->Code;
    iqualifier = msg->Qualifier;
    iaddr = (struct Gadget *) msg->IAddress;
    cSeconds = msg->Seconds;
    cMicros = msg->Micros;
}

if (msg)
    ReplyMsg( (struct Message *) msg);
else
    break;

switch (iclass)
{
    case IDCMP_CLOSEWINDOW:
        terminate = TRUE;
        break;

    ....
    ....
    ....


    case IDCMP_REFRESHWINDOW:
        /* Normally, only the damaged regions of a window
           (actually, layer) will be accessible by the gfx-
           primitives, like Text(), RectFill() and so on
           and not those which weren't damaged. This speeds up
           the drawing operations a lot, unfortunately, we
           going to spend much more time laying out and
           rotating an image so this Intuition feature
           (actually, Graphics/Layer) doesn't bother us too
           much! */
        BeginRefresh( win);
        EndRefresh( win, TRUE);
        /* Entire window is now again accessible, i.e.
           the damage regions detected by Layers library
           were thrown away and we can render in any pixel in
           the window. */

        RefreshFrames( win, &layer);
        width = layer.MaxX - layer.MinX;
        height = layer.MaxY - layer.MinY;

        FillPixelArray( win->RPort,
                        layer.MinX, layer.MinY,
                        width, height,
                        (BG_COLOUR >> 8 ) & 0x00FFFFFF);

        if (GListPtr)
        {
            if (GadgetsAccessible)
            {
                RefreshGList( GListPtr, win, NULL, -1);
            }
            else    /* IDCMP_SIZEVERIFY caused us to remove GList */
            {
                AddGList( win, GListPtr, -1, -1, NULL);
                GadgetsAccessible = 1;
                AttachGadgets( win, RgbProgressBar, glist, &gmask);
                RefreshGList( GListPtr, win, NULL, -1);
            }
        }

        /* Re-render the image */
        if (scv)
        {
            if (adaptMode == SCALE_TOFIT)
            {
                if (angle != .0)
                    cv = canvas_rotate( scv, angle, width, height, patch);
                else
                    cv = canvas_scale_rigid( scv, width, height, patch);

                if (cv)
                {
                    if (cv->sizeX > width)
                        maxX = width;
                    else
                        maxX = cv->sizeX;

                    if (cv->sizeY > height)
                        maxY = height;
                    else
                        maxY = cv->sizeY;

                    /* I know, I know. A lot of people seem to believe that
                       multiple IDCMP_REFRESHWINDOW events should be collected
                       and processed as one or that multiple refresh requests
                       should be skipped - this code proves them all wrong.
                       If the damage regions were restored properly, each
                       IDCMP_REFRESHWINDOW is essential and indicates another
                       change to the display - just uncomment the following
                       line and see what happens. When for some reason a
                       message will be removed by SkipMultiRefreshMsgs() a
                       display corruption will occur.
                    */
/*                              SkipMultiRefreshMsgs( win->UserPort, win); */

                    WritePixelArray( cv->data, 0, 0, cv->modulo,
                                     win->RPort, layer.MinX, layer.MinY,
                                     maxX, maxY, RECTFMT_RGB);

                    DisplayChanges( win, scv, cv, angle, glist, gmask);
                    UpdateZoomMenu( win, cv->scaleX);

                    canvas_free( cv);
                }
            }
            else
            {
                if (adaptMode == NOSCALE_TOFIT)
                {
                    DisplayFullSized( win, scv, angle, scalef,
                                      patch, FALSE, FALSE,
                                      &layer,
                                      deltaX, deltaY,
                                      glist, gmask);
                }
            }
        }
        break;

    case IDCMP_NEWSIZE:
        /* Never ever throw away damage regions in IDCMP_NEWSIZE -
           i.e. using Begin/EndRefresh - then
           IDCMP_REFRESHWINDOW would not be called at all! */
        #if defined(__AROS__)
        if (GadgetsAccessible)
        {
            /* Unlink the gadgets from the window */
            UncoupleGadgets( win, glist, &gmask);
            GadgetsAccessible = 0;
        }
        #endif
        break;



Zitat:
Georg:
Also ich hab' das hier (ABI V0) getestet und sowohl BltBitMapRastPort() als auch ClipBlit() funktionieren in GM_RENDER.


Ich werde eigene Tests am Wochenende/Anfang der nächsten Woche durchführen, um zu erfahren, ob dieser Bug zwischenzeitlich verschwunden ist.
Meine AROS x86 Installation ist nicht auf dem neusten Stand, daher muss ich diese erst einmal erneuern.

Zitat:
code:
tempbm = AllocBitMap(w,h,0,0,msg->gpr_RPort->BitMap);



Bei mir ist es immer ein RGB24-PixelArray (malloc()), um welches ich eine Bitmap- und Rastport-Struktur herum baue.


Zitat:
wawa:
warum testest du mit v0? es besteht glaube ich keine gerantie dass es auch unter v1 richtig arbeitet. aros68k ist v1!


Der Bug trat unter ABI v0 auf; der Funktionscode (Funktionsweise) sollte jedoch identisch in beiden Varianten sein, auch wenn die CPUs (Binärcode) und die Art der Parameterübergabe differieren.

[ - Antworten - Zitieren - Direktlink - ]

03.05.2013, 20:52 Uhr

wawa
Posts: 314
Nutzer
@jolo:
Zitat:
Im Moment, nein. Ich verwende selber für AROS x86 den 'gcc' Compiler, weiß aber, dass Frank Wille einen 'vbcc'-AROS x86 Compiler in petto hat, welcher aber noch experimentell ist. Ich habe diesen zwar auch installiert, bei mir harmoniert dieser aber nicht mit dem AROS-SDK. Ich habe zwar etliche Header-Dateien aus dem AROS-SDK für den 'vbcc'-Compiler gefixt (auch auf Assembler-Ebene), aber es ist ein unendliches Unterfangen, so dass ich irgendwann das Handtuch geworfen habe.
also nach überlegung verstehe ich glaube ich das problem und sehe eher swarz für baldige vbcc umsetzung. ich habe auch den eindruck dass vbcc mag, ähnlich wie gcc 2.9.x etwas überschätzt sein, ja es ist bestimmt mehr mit augenmerk auf 68k zugeschnitten, aber wie kann man arbeit von zwei leuten mit ganzen teams vergleichen. und ich meine auch 68k ist doch in embedded bereich noch nicht ganz tot, von daher kann man erwarten dass es zumindest rudimentär gepflegt wird.

wenn man aber auf vbcc besteht (ohne guten x86 backend und ohne c++ für manche contribs) dann wäres vielleicht leichter erstmal 68k anzupassen und zu kompilieren anstatt den buggy x86 backend. 68k kann man unter winuae leicht debuggen, und was uae nicht hergibt stehe ich mit nem a4k zur verfügung, serial debug inbegriffen.

uebrigens kannst du dir nen entsprechenden thread auf amiga coding angucken:
http://www.amigacoding.de/index.php?topic=309.msg1104#msg1104


[ - Antworten - Zitieren - Direktlink - ]

03.05.2013, 21:54 Uhr

Georg
Posts: 107
Nutzer
Zitat:
Original von jolo:

Im Moment, nein. Ich verwende selber für AROS x86 den 'gcc' Compiler, weiß aber, dass Frank Wille einen 'vbcc'-AROS x86 Compiler in petto hat, welcher aber noch experimentell ist. Ich habe diesen zwar auch installiert, bei mir harmoniert dieser aber nicht mit dem AROS-SDK. Ich habe zwar etliche Header-Dateien aus dem AROS-SDK für den 'vbcc'-Compiler gefixt (auch auf Assembler-Ebene), aber es ist ein unendliches Unterfangen, so dass ich irgendwann das Handtuch geworfen habe.


Welche Header müssen gefixt werden und welche Art von Fixes? Viele Header sind ja auto-generiert, und da müßte man ja nur die Skripte fixen, die diese erzeugen.


[ - Antworten - Zitieren - Direktlink - ]

03.05.2013, 22:01 Uhr

Georg
Posts: 107
Nutzer
Zitat:
Original von jolo:

Bei mir ist es immer ein RGB24-PixelArray (malloc()), um welches ich eine Bitmap- und Rastport-Struktur herum baue.


Wie machst du das genau?

Normalerweise würde man ja AllocBitMap() mit flags = BMF_SPECIALFMT | SHIFT_PIXFMT(PIXFMT_RGB24) verwenden.

Oder - wenn man nicht mit graphics/cgfx Funktionen in das PixelArray rendern will - überhaupt keine BitMap sondern WritePixelArray(RECTFMT_RGB).

[ - Antworten - Zitieren - Direktlink - ]

04.05.2013, 14:46 Uhr

Floppy
Posts: 392
Nutzer
@wawa

Hast Du mit Deadwood schon einmal darüber sprechen können? Oder weißt Du, ob jemand anderes daran arbeitet? Oder sollten wir abwarten, bis Georg das Problem noch mehr eingrenzen kann?

Zitat:
Original von wawa:
wanderer:
von magorium via amiga-coding.de (der link oben von olaf)
A little research shows why:
hint:http://repo.or.cz/w/AROS.git/blob?f=workbench/classes/datatypes/picture/README
and details:
http://repo.or.cz/w/AROS.git/blob?f=workbench/classes/datatypes/picture/TODO
Zitat:
PDTM_READPIXELARRAY mostly done
PDTA_DestMode (ISG) OK, but ignored internally


... so es sieht so aus als ob das ein job für das aros team wäre. ich sprech mal jetzt deadwood darauf an.




[ Dieser Beitrag wurde von Floppy am 04.05.2013 um 14:47 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

04.05.2013, 16:08 Uhr

wawa
Posts: 314
Nutzer
@Floppy:
ich hatte den eindruck bei georg ist es in richtigen händen, aber da wanderer auf aros-exec gepostet hat habe ich gerade die gelegenheit genutzt den krzysztof darauf aufmerksam zu machen.

[ - Antworten - Zitieren - Direktlink - ]

05.05.2013, 11:12 Uhr

jolo
Posts: 110
Nutzer
Zitat:
also nach überlegung verstehe ich glaube ich das problem und sehe eher schwarz für baldige vbcc umsetzung.

Dito.


Zitat:
ich habe auch den eindruck dass vbcc mag, ähnlich wie gcc 2.9.x etwas überschätzt sein, ja es ist bestimmt mehr mit augenmerk auf 68k zugeschnitten, aber wie kann man arbeit von zwei leuten mit ganzen teams vergleichen.

Erstens, ich überschätze 'vbcc' definitiv nicht, ich weiß wo dieser seine Schwachstellen hat, jedoch ist dieser dermaßen portabel, dass man selbst in der Lage ist unter 'Windows' (egal welche Version) Programme für AmigaOS3, MorphOS und AmigaOS4 zu erstellen, ohne irgendwelche Laufzeitumgebungen zu erstellen! Ich hatte schon massive Schwierigkeiten mir einen 'gcc' für AmigaOS3 zusammen zu stellen, welcher AROS-x86 Code generiert... Ergo, 'vbcc' ist portabel, 'gcc' nur schwerlich und ohne Kenntnisse gar nicht zu portieren, zudem verlangt 'gcc' nach einer LINUX-Umgebung, 'vbcc' aber nicht!
Zweitens, 'vbcc' Augenmerk liegt ganz bestimmt nicht auf CISC-Prozessoren, sondern auf RISC, auch wenn dieser klaglos 'm68k' oder auch 'x86' Code generiert, jedoch hier dann und wann Optimierungen nicht wahrgenommen werden. Nach wie vor produziert SAS/C besseren 'm68k' Code - dieser ist aber auch nicht optimal auf 'm68k' zugeschnitten (der Green Hills Software C-Compiler ist das Maß der Dinge für 'm68k' (kommerziell und nicht für AmigaOS erhältlich)) und 'gcc' besseren x86(/64) Code. CISC-Instruktionen sind für einen Compiler suboptimal, RISC-Instruktionen kommen einem Compiler jedoch sehr entgegen.
Drittens, nur einer entwickelt den 'vbcc' Compiler-Kern, und das ist Dr. Barthelmann, und da kann man nur staunen, dass einer alleine so etwas bewerkstelligt und noch dazu seinen Compiler Code generieren lässt (jedoch mit massiver Hilfe von Frank Wille), der Vergleiche mit einem 'gcc'-Compiler für 'm68k' und 'PPC' nicht scheuen muss, obschon hinter 'gcc' eine Heerschar von Programmierern steht.
Die Nachteile von 'vbcc' sind klar auf der Präprozessorseite zu suchen (der 'gcc'-Compiler erlaubt hier Dinge, die 'vbcc' nicht beherrscht) und dass 'vbcc' ausschließlich ein C-Compiler ist, während man innerhalb der GNU-Toolchain auch auf andere Programmiersprachen ausweichen kann (z.B. C++).
Viertens, 'gcc' ist die erste Wahl wenn man denn Programme von *NIX-artigen Betriebssystemen portieren will oder für x86(/64) entwickelt. Dies mache ich aber nicht bzw. nur sporadisch. Für mich steht das schnelle portieren eines Programmes innerhalb der verschiedenen Amiga-ähnlichen Betriebssysteme an erster Stelle, und da ist halt 'vbcc' die wesentlich bessere Wahl.
Zudem geht es mir nicht darum, das AROS-Btriebssystem mittels dem 'vbcc'-Compiler selber zu erstellen, sondern ausschließlich um *meine* Programme.
Aber, das ist alles am Thema vorbei; hier geht es um eventuell vorhandene AROS-Bugs und nicht um 'gcc' oder 'vbcc'.


Zitat:
Georg:
Welche Header müssen gefixt werden und welche Art von Fixes? Viele Header sind ja auto-generiert, und da müßte man ja nur die Skripte fixen, die diese erzeugen.


Wäre es nicht besser, Frank Wille direkt zu kontaktieren, anstatt meine Fixes (Hacks) als Ausgangsbasis zu benutzen? Ich habe versucht, nur ein einziges Programm mittels 'vbcci386' zu übersetzen, und ich bin kläglich gescheitert.


Zitat:
Georg:
Zitat:Original von jolo:

Bei mir ist es immer ein RGB24-PixelArray (malloc()), um welches ich eine Bitmap- und Rastport-Struktur herum baue.

Zitat:
Wie machst du das genau?

Normalerweise würde man ja AllocBitMap() mit flags = BMF_SPECIALFMT | SHIFT_PIXFMT(PIXFMT_RGB24) verwenden.

Oder - wenn man nicht mit graphics/cgfx Funktionen in das PixelArray rendern will - überhaupt keine BitMap sondern WritePixelArray(RECTFMT_RGB).



So wie Du es oben beschrieben hast:

code:
ged->bm = AllocBitMap( ((gad->Width + 15) & -16), gad->Height, 24,
                       BMF_MINPLANES | BMF_SPECIALFMT | SHIFT_PIXFMT(PIXFMT_RGB24),
                       NULL);


und bei Bedarf dann:

code:
InitRastPort( &ged->rp);
ged->rp.BitMap = ged->bm;

/* Render image to the previously created (OM_NEW) BitMap */
WritePixelArray( ged->sbutton->data, 0, 0, ged->sbutton->modulo,
                 &ged->rp, 0, 0,
                 ged->sbutton->sizeX, ged->sbutton->sizeY, RECTFMT_RGB);


wobei "ged" auf diese Struktur zeigt:

code:
struct RGBButton
{
	ULONG type;
	struct DrawInfo *drawInfo;	/* Perhaps for future versions I need it */
	struct canvas *ubutton;		/* Unselected and adapted button image */
	struct canvas *sbutton;		/* Selected and adapted button image */
	LONG  min, max, curr;		/* Progress gadget values */
	struct BitMap *bm;		/* 24-bits (RGB) */
	struct RastPort rp;		/* Private RastPort pointing to the above BitMap */
	LONG oldX, newX;		/* Only really required on the part of OS3 */
	ULONG flags;			/* See below */
};


und "canvas" das Basisabbild enthält:

code:
struct canvas	/* Always for the RGB format (each 8 bits per gun) */
{
	uint32	sizeX;		/* Width in pixel of entire canvas */
	uint32	sizeY;		/* Height in pixel of entire canvas */
	uint32	modulo;		/* Modulo (bytes per line of pixel) of canvas */
	uint32	leadin;		/* Normally 1 - so the left/top is not at 0/0 but at
				   1/1 in order to be able to apply bilinear patch */

	/* Bounding box taken by the rendered image */
	uint32	left;		/* X-offset of image in canvas */
	uint32	top;		/* Y-offset of image in canvas */
	uint32	right;		/* The width of the image */
	uint32	bottom;		/* The height of the image */

	float	scaleX;		/* The used scale factors */
	float	scaleY;

	uint32	bgRGBA;		/* RGBA background colour */
	uint8	*data;		/* Pointer to data */
};


Somit enthält "Bitmap" (ged->BitMap) nur eine Kopie der "canvas", auch wenn es noch nachträglich um grafische Elemente erweitert wird. Sollte daher unter jedem AmigaOS3 Quellcode-kompatiblen Betriebssystem funktionieren.

[ - Antworten - Zitieren - Direktlink - ]

05.05.2013, 16:50 Uhr

geit
Posts: 332
[Ex-Mitglied]
Zitat:
Original von Holger:
Zitat:
Original von tbone:
…der andere mit 8GB SSD schnarcht extrem ab, die SSD darin schreibt mit nur 1MB/s.. eine Installation von XP dauerte fast 5h inkl. Treibern, übel. Irgendwie kommt die SSD wohl mit NTFS nicht gut zurecht, aber das ist wohl Offtopic.. o)

Verwunderlich ist das wirklich nicht. Die SSD kann das Dateisystem nicht interpretieren und XP beherrscht nicht die neueren Protokolle, um der SSD klarzumachen, welche Blöcke unbelegt sind. Und 8GB sind nicht gerade eine Kapazität, bei der große Reserven vorhanden wären. Und je nach Fabrikat taugt die SSD vielleicht ohnehin nicht viel. Trotzdem könnte einmal an einem Rechner mit aktuellem Betriebssystem alles löschen etwas bringen.

Ja, SSDs werden etwas langsammer, aber auch nicht immer mehr, sondern nur noch bis zu einem Punkt und dann bleibt es konstant. Der Fehlende Trim-Support hat zwei Auswirkungen:

a) Das Medium nutzt sich schneller ab, da die SSD nicht weis welche Daten wichtig sind und welche nicht, muß sie die Daten umschichten, obwohl die Daten die sie Rettet für das Dateisystem nicht mehr relevant sind (gelöschte Dateien)

b) Das Ablaufen von Zellen und das entsprechende Ausweichen auf Reserveblöcke kostet ebenfalls mehrere Zugriffe.

Dem gegenüber kann das Laufwerk nicht fragmentieren bzw. das Suchen eines Blockes dauert immer gleich lang. Bei einer Festplatte mit SFS und vielen Dateiänderungen kann man schon bald von Hand erkennen, das die Langsam wird. Bei der SSD passiert nix.

Schlimmer als der TRIM Support ist die falsche Ausrichtung von Dateisystemblöcken. Bei 512Byte Blöcken verursacht jeder Schreibzugriff das Flashen von 4,8,16 oder gar 64 KB. Da müßte das Dateisystem optimierter schreiben und arbeiten. Aber meist ist schon die Partition Krumm, weil der RDB ein entsprechendes Offset erstellt.

Man sollte sich davon nicht verrückt machen lassen, was in den Zeitungen steht. MASSIV LANGSAMER bedeutet da schon 80MB/s oder weniger weniger. Für Amiga noide Systeme ist das komplett irrelevant, weil die Dateien so kurz sind, das es nicht auf die Ladezeiten, sondern auf die Suchzeiten ankommt und die sind immer gleich schnell.l. WIr nutzen auch keinen virtuellen Speicher etc, wo es auf jedes MB/s ankommt.

Bei einer SSD die laut Beschreibung 500MB und mehr kann, wären das immer noch etwa 420MB/s. Unglaublich wichtig, um eine 100 KB Library zu laden.

Ich kann aus eigener langjähriger Erfahrung mit Flashmedien sagen. Scheiss egal! Keines meiner Laufwerke hat jemals auch nur einen Trim-Befehl gesehen. Noch wurde es mit einem Dateisystem genutzt, das dieses kann, oder an einem Rechner der das kann.

Mein Peg2 läuft mit 512 Byte Blöcken unter SFS. Das ist wohl das schlimmste was man machen kann. Keine Probleme. Im Gegenteil: Durch die fehlende Fragmentierung und die schnellen Seekzeiten bleibt das Laufwerk schnell.

Ich will nie wieder eine Festplatte als Systemlaufwerk!

Geit

[ Dieser Beitrag wurde von geit am 05.05.2013 um 16:51 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

06.05.2013, 10:04 Uhr

Holger
Posts: 8116
Nutzer
@geit:
tbone schrieb aber von WinXP und nicht vom Amiga.
Für Amiga-Verhältnisse mag eine SSD tatsächlich immer schnell genug sein. Obwohl 1MB/s Schreibgeschwindigkeit wirklich nicht sehr berauschend sind.
Zitat:
Schlimmer als der TRIM Support ist die falsche Ausrichtung von Dateisystemblöcken. Bei 512Byte Blöcken verursacht jeder Schreibzugriff das Flashen von 4,8,16 oder gar 64 KB. Da müßte das Dateisystem optimierter schreiben und arbeiten. Aber meist ist schon die Partition Krumm, weil der RDB ein entsprechendes Offset erstellt.
Und davon ist XP auch betroffen. Und es geht noch schlimmer: ab einer bestimmten Partitionsgröße wechselt das Dateisystem auf eine Blockgröße von 4kB oder größer, die ist aber trotzdem durch die MFT-Default-Größe nicht aligned.
Zitat:
Bei einer SSD die laut Beschreibung 500MB und mehr kann, wären das immer noch etwa 420MB/s. Unglaublich wichtig, um eine 100 KB Library zu laden.
Du sprichst von aktuellen SSDs. Auf so eine würde ich bei einer Kapazität von 8GB aber nicht tippen.
Zitat:
Mein Peg2 läuft mit 512 Byte Blöcken unter SFS. Das ist wohl das schlimmste was man machen kann.
Nein, das schlimmste, was man machen kann, wäre zusätzlich zum der SSD unbekannten Dateisystem mit nicht aligned 4kB Blöcken noch eine automatische (überflüssige) Defragmentierung im Hintergrund laufen lassen. Womit wir wieder bei XP wären…
Zitat:
Ich will nie wieder eine Festplatte als Systemlaufwerk!
Kann ich verstehen.
Ich will auch nie wieder mein System von Disketten booten müssen…

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

06.05.2013, 12:12 Uhr

wawa
Posts: 314
Nutzer
@Holger:
waere vielleicht besser beim thema aros zu bleiben?

[ - Antworten - Zitieren - Direktlink - ]

06.05.2013, 13:36 Uhr

tbone
Posts: 99
Nutzer
Meinetwegen gerne! Der Thread ist gekapert, aber das aktuelle Thema wichtiger als die olle SSD und meine persönliche "Aros-Stabilitäts-Experience" (werde dazu anderswie nochmal posten).

Also, Bühne frei für die Leute an den Funktionspointern und Structs.. o)

ps:
Sorry für Multi-Edit.

[ Dieser Beitrag wurde von tbone am 06.05.2013 um 13:42 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

06.05.2013, 20:53 Uhr

Floppy
Posts: 392
Nutzer
@tbone:

Du wolltest doch mal nachsehen, welche Tools bei Dir bei welcher Benutzung zu Abstürzen führen. ;-)

[ - Antworten - Zitieren - Direktlink - ]

07.05.2013, 20:46 Uhr

jolo
Posts: 110
Nutzer
@Georg

Habe neues AROS-Kernel installiert und Tests durchgeführt. Der Bug bezüglich scheinbar gelocktem Layer ist nicht mehr vorhanden, so dass ich jetzt wieder ClipBlit() verwende.

Grüße
--
Stupid mistakes are always made by others -
we only make unavoidable errors

[ - Antworten - Zitieren - Direktlink - ]

07.05.2013, 21:06 Uhr

Floppy
Posts: 392
Nutzer
1 Punkt für AROS. ;)

Zitat:
Original von jolo:
@Georg

Habe neues AROS-Kernel installiert und Tests durchgeführt. Der Bug bezüglich scheinbar gelocktem Layer ist nicht mehr vorhanden, so dass ich jetzt wieder ClipBlit() verwende.



[ - Antworten - Zitieren - Direktlink - ]

08.05.2013, 20:44 Uhr

wawa
Posts: 314
Nutzer
@Floppy:
also das ist wohl glaube ich ergebnis der commits von neil, die ich oben erwähnt habe. leider es ist wohl noch nicht alles.

[ - Antworten - Zitieren - Direktlink - ]


1 2 -3- [ - Beitrag schreiben - ]


amiga-news.de Forum > AROS und Amiga-Emulatoren > AROS, doch noch so instabil ?! [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.