Bug in 1.4 Displaying PNG under x64 Kernel x86 app.

[David F.]

Hi,

Dang it, I hit a bug when testing the x64 kernel boot but which still uses all the x686 versions of libraries, busy box, and the main app where the graphic wasn't showing.  So I launch from a terminal and see:

XRequest.149: BadMatch (invalid parameter  attributes) 0x0

XRequest.149: BadMatch (invalid parameter  attributes) 0x0

XRequest.149: RenderBadPicture (invalid Picture parameter) 0xc00011

XRequest.149: RenderBadPicture (invalid Picture parameter) 0xc00010

XRequest.149: RenderBadPicture (invalid Picture parameter) 0xc00011

So I went back to the old FLTK 1.3.1 version that production was based on before wanting to move on to 1.4 for the high dpi displays and rebuilt the main app, copied over the binary to the same directory as the version having the problem, launched it and it came up with no messages in the terminal and the graphic was showing.

If I use the new version using FLTK 1.4 on a kernel booting 686 version, then it shows the graphic as well.

Any thoughts?

[imm]

Is your fltk built 64-bit or 32-bit (i.e. do the lib ABI's actually
match and so forth?) And if you are running 32-bit on a 64-bit host,
are the appropriate libs and so on actually in place?


Are you using the fltk built-in png lib, or the system one? I'm
guessing the system one but... Can you try with the built-in fltk
version (it's a configure option to use that in preference.)

I've hit a similar looking error in the past (when I was poking about
with nxlib, IIRC) and it was related to using a somewhat outdated png
lib version - do you know what version your system provides?
(Or it may have been a completely different error, of course!)

[David F.]

FLTK is static linked to the program.

It uses Fl_PNG_Image to show the image from the .png file.

The x64 kernel boot version vs the x686 kernel boot version are basically all the same except for the kernel itself.  All the libraries, etc.. are the 686 versions as only 686 apps run on it.  The x64 kernel is only needed because the 686 kernel won't load on some higher-end systems and some of the newer tablet type systems.

So it's weird that Xrender has a problem on one and not the other, but it does.   It looks like 1.3.1 didn't use Xrender .. If I disable Xrender will everything else (scaling and the rest of it) still work?

[Manolo]

On Friday, 7 September 2018 19:22:55 UTC+2, David F. wrote:

FLTK is static linked to the program.

It uses Fl_PNG_Image to show the image from the .png file.

The x64 kernel boot version vs the x686 kernel boot version are basically all the same except for the kernel itself.  All the libraries, etc.. are the 686 versions as only 686 apps run on it.  The x64 kernel is only needed because the 686 kernel won't load on some higher-end systems and some of the newer tablet type systems.

So it's weird that Xrender has a problem on one and not the other, but it does.   It looks like 1.3.1 didn't use Xrender .. If I disable Xrender will everything else (scaling and the rest of it) still work?

Without Xrender, scaling works (XFT is the really necessary piece) but less efficiently for images

because drawing an image to a scaled screen is done by copy-scale-cache + draw

instead of asking Xrender to draw the image at the adequate scale in one shot.

[David F.]

Okay thanks.

I'm confused on what this could be because both environment are the same except for the kernel itself.  On 686 kernel works fine, on x64 it gives the odd error.

I could think about the .so files, but that would affect 686 kernel version as well.

I can send you to two boot disks / media for you to see if you see the same thing?   Send a email.

I think I'll try disable Xrender for now, the graphic is only there to make it pretty.

[David F.]

So using --disable-xrender solved the issue on there for now.  I'm still perplexed at why only one environment had a problem with it.

[chris]

> Hi,
>
> Dang it, I hit a bug when testing the x64 kernel boot but which still
> uses all the x686 versions of libraries, busy box, and the main app
> where the graphic wasn't showing.  So I launch from a terminal and see:
>
> XRequest.149: BadMatch (invalid parameter  attributes) 0x0
> XRequest.149: BadMatch (invalid parameter  attributes) 0x0
> XRequest.149: RenderBadPicture (invalid Picture parameter) 0xc00011
> XRequest.149: RenderBadPicture (invalid Picture parameter) 0xc00010
> XRequest.149: RenderBadPicture (invalid Picture parameter) 0xc00011
>

I wonder if this can have something to do with FLTK defining the
Fl_Offscreen type (which is passed for rendering pixmaps as 'Drawable'
and which is just a typedef for 'XID') as 'unsigned long', whereas X11
defines it (in /usr/include/X11/Xdefs.h) as:

# ifndef _XSERVER64
typedef unsigned long XID;
# else
typedef CARD32 XID;
# endif

[David F.]

The interesting thing is the Xvesa and Xfbdev are still x686 versions, the only thing on the system x64 is the kernel and drivers.

That includes the apps and fltk.

[Ian MacArthur]

> On 9 Sep 2018, at 04:27, David F. wrote:
>
> The interesting thing is the Xvesa and Xfbdev are still x686 versions, the only thing on the system x64 is the kernel and drivers.
>
> That includes the apps and fltk.

That’s unknown territory for me, I think.

I have 32-bit systems, and 64-bit systems, and both work fine.

I also have 64-bit systems with *additional* 32-bit support libs added to run "legacy applications” (usually Wine on my main 64-bit machine) and that also works, but in that case the fltk builds I do are “pure” 64-bit so would not be hitting a case such as you describe...

Are we thinking that an unsuitably sized pointer is being passed, at some point?

Can we tell if this is a fltk issue, or some issue with the underlying services...?

[Darren Legge]

Sorry if this is not relavent but I think I've hit a related problem when upgrading from 1.3.1 to 1.3.4.

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  138 (RENDER)
  Minor opcode of failed request:  4 (RenderCreatePicture)

For me, the problem occurrs when the framebuffer is not truecolor.

Some of our older devices use a 16 bit (5:6:5) framebuffer and our app with fltk1.3.4 won't work for me on these without --disable-xrender.

If I set the framebuffer to 24 bit on these devices xrender works fine. Of course fltk1.3.1 did not use xrender.

Maybe this might shed some light on the cause of your problem...

[Ian MacArthur]

> On 31 Jul 2019, at 16:06, Darren Legge wrote:
>
> X Error of failed request: BadMatch (invalid parameter attributes)
> Major opcode of failed request: 138 (RENDER)
> Minor opcode of failed request: 4 (RenderCreatePicture)
> For me, the problem occurrs when the framebuffer is not truecolor.
> Some of our older devices use a 16 bit (5:6:5) framebuffer and our app with fltk1.3.4 won't work for me on these without --disable-xrender.
> If I set the framebuffer to 24 bit on these devices xrender works fine.

I’m afraid I’ve nothing *useful* to say here but...

> Of course fltk1.3.1 did not use xrender.

Is this true? ISTR we have been using the Xrender extension for a *long* time, if configure finds it... So I *think* that 1.3.1 would use the Xrender extension, if it was detected during configure...

But I could well be mistaken about that!

[Darren Legge]

Ok, I was just going by the CHANGES document in 1.3.4 which mentions "Drawing alpha-blended images under X11 is now accelerated with
 Xrender." so assumed it wasn't used before them.

However, the macro HAVE_XRENDER is not defined (as 1 or 0) in the config before 1.3.4 and I don't find the text 'Xrender.h'

 in src/ anywhere !

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/FJYEag5cKNY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/E4C47278-90B5-4A77-9C74-2AC5FE44A624%40gmail.com.

[Albrecht Schlosser]

On 8/1/19 10:00 AM Darren Legge wrote:
> Ok, I was just going by the CHANGES document in 1.3.4 which mentions
> "Drawing alpha-blended images under X11 is now accelerated with
>  Xrender." so assumed it wasn't used before them.
> However, the macro HAVE_XRENDER is not defined (as 1 or 0) in the config
> before 1.3.4 and I don't find the text 'Xrender.h'
>  in src/ anywhere !

FWIW: Xrender support was indeed added in 1.3.4, svn r10622:

$ git log -1 a6c4b29a1
commit a6c4b29a184ce7708819f4706877eedcd99a30f5
Date: Mon Mar 16 11:07:00 2015 +0000

Detect XRender support

(after the release of 1.3.3).

[Manolo]

@Darren: could you, please, perform this check on the system with the 16-bit framebuffer?

Get with the debugger or a print statement the value of variables srcfmt and dstfmt

from function Fl_Xlib_Graphics_Driver::copy_offscreen_with_alpha in file src/Fl_Double_Window.cxx

at lines 145 and 146 (that's for FLTK 1.3.5).

Please report if any of these variables is NULL.

XRender is used to draw transparent RGB images in FLTK 1.3.5.

In 1.4 it's also used to scale images which is handy in the context of highDPI displays.

FLTK asks the running X server for XRender support, but there migh be some implicit requirement

of truecolor in the present code. The test above could help clarifying that.

[Manolo]

On Saturday, 3 August 2019 15:10:01 UTC+2, Manolo wrote:

@Darren: could you, please, perform this check on the system with the 16-bit framebuffer?

Get with the debugger or a print statement the value of variables srcfmt and dstfmt

from function Fl_Xlib_Graphics_Driver::copy_offscreen_with_alpha in file src/Fl_Double_Window.cxx

at lines 145 and 146 (that's for FLTK 1.3.5).

Please report if any of these variables is NULL.

While at it, could you, please, try replacing in the same function line #146 presently

  static XRenderPictFormat *dstfmt = XRenderFindStandardFormat(fl_display, PictStandardRGB24);
by

  static XRenderPictFormat *dstfmt = XRenderFindVisualFormat(fl_display, fl_visual->visual);

and report what happens?

TIA

[Darren Legge]

Hi Manolo

Thanks for looking at this. I'm sorry for the delay but with holidays and other things going on I literally have not been in the office for a month.

Neither of the pointers were NULL, but the code change to use XRenderFindVisualFormat() fixed the problem so FLTK with XRender works on 16bpp framebuffer (for me at least...)

I'm happy to perform any other tests you think useful.

I hope this info is helpful for FLTK moving forward !

Darren.

[Manolo]

@Darren:   great. The code change that calls XRenderFindVisualFormat() has been committed to the git repository

for both FLTL 1.3 and 1.4