That someone was me ;-).

Monochrome (and 4-bit) images have their pixels from high to low in win32. So bit 7 is pixel 0, bit 0 is pixel 7. I assume something similar holds for 4-bit images.

That means a further IF in the Get/SetPixel function, which is a very time critical function. I suggest to implement one all rounder function plus several optimized functions for commong formats. The Get/SetPixel then uses an event.

Good idea.

ToDo: - first you have to find out the byte and bit order under win32. (Draw some very simple images (5x5, 8x8, 13x13, 18x18, 26x26 and 34x34) with a few lines.

For monochrome images, I explained above. I believe there is no problem with byte order. Byte order is parameterized already anyway.

- fix the Get/SetPixel code (with some IFDEFs).

Okay will do.

- you have to try 15/16/24/32 bit depths of the window dektop. - then we can add the missing BitOrder/ByteOrder to the TRawImageDescription

We'll need a bitorder I guess.

- then we can implement the all rounder functions. - then we add the optimized functions. I hope, this was clear. If not, just mail.

Very clear :-). I'll try some coding, commit and report here, then you can take a look.

Micha.

Done. I used {$ifdef win32}, it should be easy to find, I think :-). I leave the implementation of generic byte/bit order in your capable hands (as you know the code better), or just say the word, and I'll take a look.

- you have to try 15/16/24/32 bit depths of the window dektop. - then we can add the missing BitOrder/ByteOrder to the TRawImageDescription - then we can implement the all rounder functions. - then we add the optimized functions.

Regards,

Micha.

Hi,

Very recently colours are wrong on win32. It happens only when using -dUseFPImage. I think it has to do with recent "fpImage streaming fixed" which I saw in the logs? AFAICS, no colour related things have changed in the win32 interface.

Regards,

Micha.

I guess, it has something to do with the calculation of the bit offset in intfgraphics.pp. Someone changed this a few weeks ago and I didn't notice it till yesterday, that this broke the gtk side.

Probably it is related to the "Byte Order" misunderstanding. As I said, I didn't implemented it yet, because I hoped, that it is solely processor dependent and we do not yet support powerpc. But it seems that even win32 and X do not use the same byte/bit order for images. So, we have to implement it now.
That means a further IF in the Get/SetPixel function, which is a very time critical function. I suggest to implement one all rounder function plus several optimized functions for commong formats. The Get/SetPixel then uses an event.

ToDo:
- first you have to find out the byte and bit order under win32. (Draw some very simple images (5x5, 8x8, 13x13, 18x18, 26x26 and 34x34) with a few lines.
- fix the Get/SetPixel code (with some IFDEFs).
- you have to try 15/16/24/32 bit depths of the window dektop.
- then we can add the missing BitOrder/ByteOrder to the TRawImageDescription
- then we can implement the all rounder functions.
- then we add the optimized functions.

I hope, this was clear. If not, just mail.

Mattias

I think, the optimizations will have the form:

If (not HasPalette) and (BitsPerpixel=32) and (RedPrec=8) and ... then
  Choose_24of32Bit_LSB_GetSetColorFunctions;

This is independent of palettes.

About palettes:
I don't have the needed knowledge to create an useful palette system working for all platforms. For speed reasons, someone should read the gtk docs carefully and probably also some of gtk/X sources and tell us, what is fast and what not. Also we need conversion functions.

Mattias

Done. I used {$ifdef win32}, it should be easy to find, I think :-). I leave the implementation of generic byte/bit order in your capable hands (as you know the code better),

Implemented.
Now we can add optimized Get/Set pixel methods.

Mattias

Micha Nelissen wrote

Very recently colours are wrong on win32. It happens only when using -dUseFPImage. I think it has to do with recent "fpImage streaming fixed" which I saw in the logs? AFAICS, no colour related things have changed in the win32 interface.

Okay, the colours still aren't correct :-(. They are correct if I set my desktop depth to 32 bit. At 16 bit it doesn't work. Don't know about 24 bit, my video card doesn't support that. Mattias, could you look into 24 to 16 bit conversion of images? I guess that has to do with it.

Regards,

Micha.

The 24 of the image is irrelevant.
If the 16 bit writing does not work, then
- either the win32 intf has set the wrong shift and prec values
- or WriteRawImageBits in intfgraphics.pas for BitsPerPixel=16 has to change lo and hi byte.

The 5 lines in WriteRawImageBits simply replace some bits of a word. If you think, that the win32 intf has set the right values then you can try to replace

  TwoBytes:=PWord(P)^;

with

  TwoBytes:=(PByte(P)^ shl 8)+PByte(P)^;

The only way to make sure: I suggest you create a bitmap in 16 bit mode, paint it red, then green, then blue and read the first word, to see how windows manages colors.

Mattias

Maybe we should implement palettes first, because that may be much harder once the optimizations are done?

Regards,

Micha.

Yes. XPM has always a palette.

Does this indicate a failure in fpimage to load paletted images?

No. see below.

I assume it does work in gtk?

Yes.

To reduce the confusion:
fpImage splitts and modularizes the reading/writing of images. For example the XPM reader parses a stream and converts each pixel into a TFPColor, to call SetPixel for each pixel. So, this conversion is XPM -> TFPColor (48bit depth). Theoretically XPM supports more than 48 bit depth, but practically not, therefore this conversion is lossless. The TLazIntfImage overrides the SetPixel method and sets the pixel according to the RawImage format. This can result in loss of color information.

So, yes, the splash logo is paletted, and no, fpImage has no problem with it.
When you save an XPM, the palette is created on the fly.

Mattias

It's fixed now. Wrong color format, 5-5-5 instead of 5-6-5. Maybe this info is retrievable from win32 api / device, instead of hardcoded, but I don't know how.

Regards,

Micha.

Is there a way to get the lazarus logo as file, lazarus.xpm or so? Then I can make a seperate test app, debugging the ide is quite a lot of code ;-).

Micha.

See lazarus/images/splash_logo.xpm and
lazarus/images/lazarus_about_logo.xpm.

HTH,
Vincent.

This doesn't work for me. It returns 6, while it should return 5. If it would return 5, something is wrong in color handling of windows, I think, but I'm not sure.

Regards,

Micha.

Ok. My hunt continues... ;-)

Micha.

Thanks for the hint. It seems this is a paletted image, is that right? Does this indicate a failure in fpimage to load paletted images? I assume it does work in gtk?

Micha.