Rawimage - in 256c or less modes

[amiga-mui]

Rawimage - in 256c or less modes

[jens-maus]

Michael changed status from pending to new

[jens-maus]

Michael uploaded file MUI-NEWSTUFF-256c.PNG (39.8 KiB):

[jens-maus]

Michael uploaded file MUI-NEWSTUFF2-256c.PNG (27.3 KiB):

[jens-maus]

@tboeckel changed status from new to assigned

[jens-maus]

@tboeckel changed component from Rawimage.mcc to Pixmap.mui

[jens-maus]

@tboeckel changed priority from undecided to normal

[jens-maus]

@tboeckel changed owner from ** to tboeckel

[jens-maus]

@tboeckel commented:

As the name suggests Rawimage.mcc does handle embedded raw image data. There is nothing that the datatypes system can do here. Do not jump to conclusions if you don't know how certain stuff works internally.

[jens-maus]

@tboeckel changed status from assigned to closed

[jens-maus]

@tboeckel changed resolution from ** to fixed

[jens-maus]

@tboeckel commented:

In amiga-mui/mui@f825937860331161af291fcee2b329a861442638:

• Pixmap.c: use graphics/WritePixelArray8() to convert the dithered chunky data into a bitmap in case CyberGraphics is not available. This closes #42 and closes #49.

[jens-maus]

Michael commented:

Ok. It was not a conclusion, rather an idea how to solve it easier if there is no remapping algorithm inside mui. And as far as I understand under AOS the main library behind all the fun is picture.datatype, it effects a lot of things not even connected to it (from the usual users point of view).

Can't wait for tomorrow to see how things progress ;-)

[jens-maus]

@tboeckel commented:

Please keep in mind that MUI 3.9 is definitely targeted for powerful systems being equipped with a fast CPU and a graphic board (CGX or P96). As such the dithered images for colormapped 8bit screens will never look as good as the unmodified images on hi/truecolor screens. And less colors make it even worse. Face it, time is moving forward and planar screens are far too slow anyway. Even an RTG 8bit screen is far below common standards in 2014.

[jens-maus]

Michael commented:

I don't have many problems with that, working in hicolour since first weeks the cgx gfx board was released. But we have to accept that in some situations the application needs to work in lower colour modes, besides MUI is a layout engine and it should not be the reason for the application to fail.
Even these days extreme resolutions with 256c and even 16c have a lot of use.
Since they use a lot of memory and require high bandwidth from the hardware.

[jens-maus]

@jens-maus commented:

Replying to [comment:5 Michael]:

I don't have many problems with that, working in hicolour since first weeks the cgx gfx board was released. But we have to accept that in some situations the application needs to work in lower colour modes, besides MUI is a layout engine and it should not be the reason for the application to fail.
Even these days extreme resolutions with 256c and even 16c have a lot of use.
Since they use a lot of memory and require high bandwidth from the hardware.

Sorry, but this is out of discussion here since it is our decision which way to go. And we have decided to consider low color screens as well as slow classic machines (< 68060) a low priority with only limited to no support at all. We have definitely targeted MUI3.9 for m68k to be used in emulation environments mainly (like WinUAE primarily). Thus, there is no reason for us to support older, slower and obsolete systems. We are in 2014, so face the truth that classic systems are obsolete. Period.

[jens-maus]

Michael commented:

No objection regarding cosmetic and fancy things, just one,
that it has to work even under emulation in some conditions.
And one of them is when you have a broken system and need to do something,
that means you are left with chipset graphics (real or emulated).
eg. even a MUI screenmode prefs tool will not work resulting in a dead end situation, since changing screenmode will be impossible. (wb replacements, scalos) or other system tools that need to be run in early start up cases.

So again, I repeat myself that I do agree with you, limited support is fine, but it has to work, and there is no reason why it should not.

[jens-maus]

Michael uploaded file MUI39N.PNG (43.0 KiB):

Broken GFX output

[jens-maus]

Michael changed status from closed to reopened

[jens-maus]

Michael changed resolution from fixed to **

[jens-maus]

Michael commented:

Have not checked AGA output yet.
CGX 8-bit rendering is still broken, but looks different now.

[jens-maus]

Michael commented:

Actually it's impossible to check it under AGA at the moment since MUI fails to start with cybergraphics.library missing and just crashes. BUG #54

[jens-maus]

Michael commented:

Update: Using CGXAGA driver enables starting of current MUI builds under AGA,
but then the results are the same as with CGX/RTG 8-bit. Trashed images (only old style MWB images in prefs work)

[jens-maus]

Michael uploaded file MUI-39old-GOOD-IMAGES.png (58.0 KiB):

Older MUI with good images on low colour screen (64 in this example)

[jens-maus]

Michael commented:

[[Image(MUI-39old-GOOD-IMAGES.png)]] Old MUI39 demonstrates working image lists in low colour for all images, simple and modern colourful ones.
[[Image(MUI39N.PNG)]]

[jens-maus]

@tboeckel uploaded file newstuff.png (18.2 KiB):

screenshot of NewStuff demo running on 8bit 640x512 PAL screen

[jens-maus]

@tboeckel changed status from reopened to pending

[jens-maus]

@tboeckel commented:

For me everything works perfectly on a plain system without CGX. Even the border gadgets are drawn correctly without any patches.[[Image(newstuff.png)]]

[jens-maus]

Michael commented:

Confirmed. AGA works now.
But CGX 8 bit is still crap for all images, including About window.
Only it looks slightly different now (3rd version of mixed pixels)

Under 16-bit Pixmap seems to be a lot faster now compared to a few versions back.

[jens-maus]

@tboeckel commented:

Replying to [comment:14 Michael]:

But CGX 8 bit is still crap for all images, including About window.
Only it looks slightly different now (3rd version of mixed pixels)

Please provide a screenshot of these wrong images.

Under 16-bit Pixmap seems to be a lot faster now compared to a few versions back.

Nothing has been changed in that respect.

[jens-maus]

Michael uploaded file MUI-2014-07-16.png (61.0 KiB):

8bit CGX

[jens-maus]

Michael commented:

[[Image(MUI-2014-07-16.png​)]] 8bit CGX
You wish is my command, Master... Photo

All colourful images are broken,
the about window is broken too and takes some seconds to open!
Guess something heavy doing with remapping of the picture.

Slight offset (by 1 pxl) of window gadgets. (Compare to above lister)
And min window dimensions. I think we need a few pixels left for the middle drag bar too.

[jens-maus]

@tboeckel commented:

Please try again with the next nightly build. I added a few changes for the titlebar images in case VisualPrefs is active.

Regarding the wrong dithered images I think I will have to add some more debug output to track this issue down.

[jens-maus]

@tboeckel uploaded file Pixmap_dbg.lha (7.1 KiB):

debug version of Pixmap.mui

[jens-maus]

@tboeckel commented:

Please create an IMAGE debug log using the attached debug version of Pixmap.mui.

[jens-maus]

Michael uploaded file colours2.png (42.4 KiB):

[jens-maus]

Michael commented:

[[Image(colours2.png)]]
The Circle palette tool works sort of on AGA, but fails with CGX 8bit, and is ridiculously slow, like 10 seconds for one update on 85MIPS cpu!.
Why can't you just implement normal RGB sliders for 8 bit screens?
Will save a lot of nerves.

Actually do we have RGB for 24bits, or we are stuck with HSV ?

And finally, can the default size of this window be a bit smaller ?
The fancy thing is ok when it's roughly half of what it is by default.
And opening time will be reduce considerably.

[jens-maus]

Michael uploaded file log-4.txt (29.8 KiB):

[jens-maus]

Michael commented:

First part of log is MUIPrefs - all images broken in 8 bits
Second part (External classes) most images are ok, some broken
End - new stuff - boing balls, broken

[jens-maus]

@tboeckel commented:

Try again with the next nightly build. There is no more difference between CyberGraphics and native chipsets when generating the dithered bitmap. If AGA was working before then CyberGraphics must work now as well.

[jens-maus]

@tboeckel changed status from new to closed

[jens-maus]

@tboeckel changed resolution from ** to fixed

[jens-maus]

@tboeckel commented:

In amiga-mui/mui@47875fecbe2edddcaa5519da4c3223a43750f33c:

• mastergfx.c: optimized the dithering process by using a common web palette which offers a MUCH faster rendering. This closes #49 and closes #62.

[jens-maus]

Michael commented:

Yes, finally it works in all (I hope) modes.

There is something wrong with the colour wheel, it can't be that slow.
Tried MUI under OS4 and compared to 060, that's at least 10-20 times faster!
But the CPU is only 3 times faster, and the rest of the system is the same.

In 8 bits, it refreshes once every 5-10 seconds, depending on window size.
Totally unusable since response from the GUI is missing and the rendering process
takes all the CPU time, when it should break if there was input and not lockup until completed.