Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#49 closed bug (fixed)

Rawimage - in 256c or less modes

Reported by: Mikhail Malyshev Owned by: Thore Böckelmann
Priority: normal Milestone: 3.9-2014R2
Component: Pixmap.mui Version: 3.9-2014R1
Severity: minor Keywords:
Cc: OS Platform: AmigaOS3
Blocked By: Blocking:
Release Notes:

Description

Does not render anything useful in low colour modes.
Can use picture/datatypes dithering for showing something useful in ⇐8 bit modes.

Attachments (9)

MUI-NEWSTUFF-256c.PNG (39.8 KB) - added by Mikhail Malyshev 5 years ago.
MUI-NEWSTUFF2-256c.PNG (27.3 KB) - added by Mikhail Malyshev 5 years ago.
MUI39N.PNG (43.0 KB) - added by Mikhail Malyshev 5 years ago.
Broken GFX output
MUI-39old-GOOD-IMAGES.png (58.0 KB) - added by Mikhail Malyshev 5 years ago.
Older MUI with good images on low colour screen (64 in this example)
newstuff.png (18.2 KB) - added by Thore Böckelmann 5 years ago.
screenshot of NewStuff demo running on 8bit 640x512 PAL screen
MUI-2014-07-16.png (61.0 KB) - added by Mikhail Malyshev 5 years ago.
8bit CGX
Pixmap_dbg.lha (7.1 KB) - added by Thore Böckelmann 5 years ago.
debug version of Pixmap.mui
colours2.png (42.4 KB) - added by Mikhail Malyshev 5 years ago.
log-4.txt (29.8 KB) - added by Mikhail Malyshev 5 years ago.

Download all attachments as: .zip

Change History (34)

comment:1 Changed 50 years ago by Mikhail Malyshev

Status: pendingnew

Changed 5 years ago by Mikhail Malyshev

Attachment: MUI-NEWSTUFF-256c.PNG added

Changed 5 years ago by Mikhail Malyshev

Attachment: MUI-NEWSTUFF2-256c.PNG added

comment:1 Changed 5 years ago by Thore Böckelmann

Component: Rawimage.mccPixmap.mui
Milestone: MUI 3.9-2014R2
Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

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.

comment:2 Changed 5 years ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed

In 3637:

  • 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.

comment:3 Changed 5 years ago by Mikhail Malyshev

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 ;-)

comment:4 Changed 5 years ago by Thore Böckelmann

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.

comment:5 Changed 5 years ago by Mikhail Malyshev

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.

comment:6 in reply to:  5 Changed 5 years ago by Jens Maus

Replying to 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.

comment:7 Changed 5 years ago by Mikhail Malyshev

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.

Changed 5 years ago by Mikhail Malyshev

Attachment: MUI39N.PNG added

Broken GFX output

comment:8 Changed 5 years ago by Mikhail Malyshev

Resolution: fixed
Status: closedreopened

comment:9 Changed 5 years ago by Mikhail Malyshev

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

comment:10 Changed 5 years ago by Mikhail Malyshev

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

comment:11 Changed 5 years ago by Mikhail Malyshev

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)

Changed 5 years ago by Mikhail Malyshev

Attachment: MUI-39old-GOOD-IMAGES.png added

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

comment:12 Changed 5 years ago by Mikhail Malyshev

Older MUI with good images on low colour screen (64 in this example) Old MUI39 demonstrates working image lists in low colour for all images, simple and modern colourful ones.
Broken GFX output

Changed 5 years ago by Thore Böckelmann

Attachment: newstuff.png added

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

comment:13 Changed 5 years ago by Thore Böckelmann

Status: reopenedpending

For me everything works perfectly on a plain system without CGX. Even the border gadgets are drawn correctly without any patches.screenshot of NewStuff demo running on 8bit 640x512 PAL screen

comment:14 Changed 5 years ago by Mikhail Malyshev

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.

comment:15 in reply to:  14 Changed 5 years ago by Thore Böckelmann

Replying to 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.

Changed 5 years ago by Mikhail Malyshev

Attachment: MUI-2014-07-16.png added

8bit CGX

comment:16 Changed 5 years ago by Mikhail Malyshev

8bit CGX 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.

Last edited 5 years ago by Mikhail Malyshev (previous) (diff)

comment:17 Changed 5 years ago by Thore Böckelmann

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.

Changed 5 years ago by Thore Böckelmann

Attachment: Pixmap_dbg.lha added

debug version of Pixmap.mui

comment:18 Changed 5 years ago by Thore Böckelmann

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

Changed 5 years ago by Mikhail Malyshev

Attachment: colours2.png added

comment:19 Changed 5 years ago by Mikhail Malyshev


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.

Changed 5 years ago by Mikhail Malyshev

Attachment: log-4.txt added

comment:20 Changed 5 years ago by Mikhail Malyshev

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

comment:21 Changed 5 years ago by Thore Böckelmann

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.

comment:22 Changed 5 years ago by Thore Böckelmann

Resolution: fixed
Status: newclosed

In 3723:

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

comment:23 Changed 5 years ago by Mikhail Malyshev

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.

comment:24 Changed 5 years ago by Thore Böckelmann

Milestone: MUI 3.9-2014R23.9-2014R2

Milestone renamed

Note: See TracTickets for help on using tickets.