Bug #115967 for Graphics-Framebuffer: Bug with ttf

Fri Jul 08 01:35:00 2016 snowrodeo [...] gmail.com - Ticket created

Subject:	Bug with ttf_print
Date:	Thu, 7 Jul 2016 22:34:40 -0700
To:	bug-Graphics-Framebuffer [...] rt.cpan.org
From:	Erik Olson <snowrodeo [...] gmail.com>

Hi again, I am seeing another bug(s) with ttf_print. 1) There seems to be an extra 'line' below the line printed. So if I print at, say (40,40) with a height of 30, there seems to be a discolored area below the printed line that seems to be about double the intended height 2) When I intentionally overlap another line of text into this lower region, the discoloration is worse (see the "Lin" in the picture) 3) When the lower section is below the bottom of the frame buffer, nothing prints. See the black hunk at the bottom Attached files: 1) iPhone picture 2) Code 3) Dumper data Please let me know what I can do to help debug. Thanks, -Erik

Message body is not shown because sender requested not to inline it.

Download FullSizeRender.jpg
image/jpeg 82.1k

Message body is not shown because sender requested not to inline it.

Fri Jul 08 13:02:17 2016 rich [...] rk-internet.com - Correspondence added

Subject:	Re: [rt.cpan.org #115967] Bug with ttf_print
Date:	Fri, 8 Jul 2016 11:01:55 -0600
To:	bug-Graphics-Framebuffer [...] rt.cpan.org
From:	Richard Kelsch <rich [...] rk-internet.com>

Well, it's not exactly *ttf_print* that is the problem, but it does suffer from it. There's a color remapping issue with 16 bit mode I am working on currently. You see, "*Imager*" is all 32/24 bit only, and to make it work with 16 bit, I have to convert between color modes. If the code isn't exactly right, you can get artifacts. Most of my development has been on 32 bit mode output, but when I ran on a *Raspberry PI2* recently (which I use for 16 bit testing), I noticed these artifacts on all operations using *Imager*. I have recently accelerated the 32 bit to 16 bit and 32 bit to 16 bit conversion routines (in C code) to make these operations quick for folks with 16 bit TFT displays. However, some bugs have crept in. While I attempt to fix this, as a test, try nesting these commands around your ttf_print code to see if they "fix" the artifacting. Note, this will make ttf_print considerably slower, and this is only a test, as I will get you corrected code soon. I don't expect you to use this in your "production" code. I just want to see if it fixes things visually: $f->acceleration(0); $f->ttf_print....etc $f->acceleration(1); This will force the engine to use the Perl routines. Let me know if anything changes. Meanwhile I will get what issues I can find fixed on my end for you. Rich On 7/7/2016 11:35 PM, Erik Olson via RT wrote: Show quoted text

> Fri Jul 08 01:35:00 2016: Request 115967 was acted upon. > Transaction: Ticket created by snowrodeo@gmail.com > Queue: Graphics-Framebuffer > Subject: Bug with ttf_print > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: snowrodeo@gmail.com > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > > Hi again, > > I am seeing another bug(s) with ttf_print. > > 1) There seems to be an extra 'line' below the line printed. So if I print > at, say (40,40) with a height of 30, there seems to be a discolored area > below the printed line that seems to be about double the intended height > 2) When I intentionally overlap another line of text into this lower > region, the discoloration is worse (see the "Lin" in the picture) > 3) When the lower section is below the bottom of the frame buffer, nothing > prints. See the black hunk at the bottom > > Attached files: > 1) iPhone picture > 2) Code > 3) Dumper data > > Please let me know what I can do to help debug. > > Thanks, > > -Erik >

Fri Jul 08 13:02:18 2016 The RT System itself - Status changed from 'new' to 'open'

Fri Jul 08 14:12:27 2016 snowrodeo [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #115967] Bug with ttf_print
Date:	Fri, 8 Jul 2016 11:12:10 -0700
To:	bug-Graphics-Framebuffer [...] rt.cpan.org
From:	Erik Olson <snowrodeo [...] gmail.com>

Thanks Rich, I turned off acceleration as you suggested and the output changed slightly - see the attached picture. The overlapping sections have the right color now. Do you think the 16 bit Imager issue is responsible for not being about to print "lower" in the screen as well? That is the one that is a killer for me, but I have other parts of the project I can work on so life continues! ;-) Thanks again! -Erik On Fri, Jul 8, 2016 at 10:02 AM, Richard Kelsch via RT < bug-Graphics-Framebuffer@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > Well, it's not exactly *ttf_print* that is the problem, but it does > suffer from it. There's a color remapping issue with 16 bit mode I am > working on currently. You see, "*Imager*" is all 32/24 bit only, and to > make it work with 16 bit, I have to convert between color modes. If the > code isn't exactly right, you can get artifacts. > > Most of my development has been on 32 bit mode output, but when I ran on > a *Raspberry PI2* recently (which I use for 16 bit testing), I noticed > these artifacts on all operations using *Imager*. I have recently > accelerated the 32 bit to 16 bit and 32 bit to 16 bit conversion > routines (in C code) to make these operations quick for folks with 16 > bit TFT displays. However, some bugs have crept in. > > While I attempt to fix this, as a test, try nesting these commands > around your ttf_print code to see if they "fix" the artifacting. Note, > this will make ttf_print considerably slower, and this is only a test, > as I will get you corrected code soon. I don't expect you to use this > in your "production" code. I just want to see if it fixes things visually: > > $f->acceleration(0); > $f->ttf_print....etc > $f->acceleration(1); > > This will force the engine to use the Perl routines. Let me know if > anything changes. Meanwhile I will get what issues I can find fixed on > my end for you. > > Rich > > On 7/7/2016 11:35 PM, Erik Olson via RT wrote:

> > Fri Jul 08 01:35:00 2016: Request 115967 was acted upon. > > Transaction: Ticket created by snowrodeo@gmail.com > > Queue: Graphics-Framebuffer > > Subject: Bug with ttf_print > > Broken in: (no value) > > Severity: (no value) > > Owner: Nobody > > Requestors: snowrodeo@gmail.com > > Status: new > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > > > > > Hi again, > > > > I am seeing another bug(s) with ttf_print. > > > > 1) There seems to be an extra 'line' below the line printed. So if I

> print

> > at, say (40,40) with a height of 30, there seems to be a discolored area > > below the printed line that seems to be about double the intended height > > 2) When I intentionally overlap another line of text into this lower > > region, the discoloration is worse (see the "Lin" in the picture) > > 3) When the lower section is below the bottom of the frame buffer,

> nothing

> > prints. See the black hunk at the bottom > > > > Attached files: > > 1) iPhone picture > > 2) Code > > 3) Dumper data > > > > Please let me know what I can do to help debug. > > > > Thanks, > > > > -Erik > >

> > >

Download IMG_5085.JPG
image/jpeg 73.9k

Message body is not shown because sender requested not to inline it.

Sat Jul 09 06:49:46 2016 rich [...] rk-internet.com - Correspondence added

Subject:	Re: [rt.cpan.org #115967] Bug with ttf_print
Date:	Sat, 9 Jul 2016 04:41:15 -0600
To:	bug-Graphics-Framebuffer [...] rt.cpan.org
From:	Richard Kelsch <rich [...] rk-internet.com>

I suspect the empty output on the lower part of the screen can be related to these issues. I'll try to fix the system as it is designed, but I am considering (for the next major version upgrade), to double-buffer 16 bit mode, and the only conversions done are on the whole framebuffer at once, using a dirty flag for updates. So basically it would be drawing to a 24 (or 32) bit internal buffer, and then that is dumped to the real framebuffer as it is converted to 16 bit. This would certainly increase accuracy, but may introduce a slight lag. It would depend on the CPU speed. That is dependent on whether I can get this working reliably as it is now. We'll see if I can fix the 16 bit issues today. Converting to double-buffering, would be a large project, and I prefer to not have to do that. Rich On 7/8/2016 12:12 PM, Erik Olson via RT wrote: Show quoted text

> Queue: Graphics-Framebuffer > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > Thanks Rich, > > I turned off acceleration as you suggested and the output changed slightly > - see the attached picture. The overlapping sections have the right color > now. > > Do you think the 16 bit Imager issue is responsible for not being about to > print "lower" in the screen as well? That is the one that is a killer for > me, but I have other parts of the project I can work on so life continues! > ;-) > > Thanks again! > > -Erik > > On Fri, Jul 8, 2016 at 10:02 AM, Richard Kelsch via RT < > bug-Graphics-Framebuffer@rt.cpan.org> wrote: >

>> <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >> >> Well, it's not exactly *ttf_print* that is the problem, but it does >> suffer from it. There's a color remapping issue with 16 bit mode I am >> working on currently. You see, "*Imager*" is all 32/24 bit only, and to >> make it work with 16 bit, I have to convert between color modes. If the >> code isn't exactly right, you can get artifacts. >> >> Most of my development has been on 32 bit mode output, but when I ran on >> a *Raspberry PI2* recently (which I use for 16 bit testing), I noticed >> these artifacts on all operations using *Imager*. I have recently >> accelerated the 32 bit to 16 bit and 32 bit to 16 bit conversion >> routines (in C code) to make these operations quick for folks with 16 >> bit TFT displays. However, some bugs have crept in. >> >> While I attempt to fix this, as a test, try nesting these commands >> around your ttf_print code to see if they "fix" the artifacting. Note, >> this will make ttf_print considerably slower, and this is only a test, >> as I will get you corrected code soon. I don't expect you to use this >> in your "production" code. I just want to see if it fixes things visually: >> >> $f->acceleration(0); >> $f->ttf_print....etc >> $f->acceleration(1); >> >> This will force the engine to use the Perl routines. Let me know if >> anything changes. Meanwhile I will get what issues I can find fixed on >> my end for you. >> >> Rich >> >> On 7/7/2016 11:35 PM, Erik Olson via RT wrote:

>>> Fri Jul 08 01:35:00 2016: Request 115967 was acted upon. >>> Transaction: Ticket created by snowrodeo@gmail.com >>> Queue: Graphics-Framebuffer >>> Subject: Bug with ttf_print >>> Broken in: (no value) >>> Severity: (no value) >>> Owner: Nobody >>> Requestors: snowrodeo@gmail.com >>> Status: new >>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >>> >>> >>> Hi again, >>> >>> I am seeing another bug(s) with ttf_print. >>> >>> 1) There seems to be an extra 'line' below the line printed. So if I

>> print

>>> at, say (40,40) with a height of 30, there seems to be a discolored area >>> below the printed line that seems to be about double the intended height >>> 2) When I intentionally overlap another line of text into this lower >>> region, the discoloration is worse (see the "Lin" in the picture) >>> 3) When the lower section is below the bottom of the frame buffer,

>> nothing

>>> prints. See the black hunk at the bottom >>> >>> Attached files: >>> 1) iPhone picture >>> 2) Code >>> 3) Dumper data >>> >>> Please let me know what I can do to help debug. >>> >>> Thanks, >>> >>> -Erik >>>

>> >>

Sat Jul 09 22:55:42 2016 rich [...] rk-internet.com - Correspondence added

Subject:	Re: [rt.cpan.org #115967] Bug with ttf_print
Date:	Sat, 9 Jul 2016 20:55:16 -0600
To:	bug-Graphics-Framebuffer [...] rt.cpan.org
From:	Richard Kelsch <rich [...] rk-internet.com>

I have uploaded a new version to CPAN (5.90). Attached is a new script for you to try. I have decided to implement double-buffering. The attached script uses it. It basically draws to a 32 bit virtual framebuffer and calls a new method "blit_flip" to convert it to the real 16 bit framebuffer. Pay careful attention to how both are created. Also, due to the fact RAM buffering is used, "FILE_MODE" is ineffective. It's best if you leave that off (it will be going away eventually anyway). I did testing here with my 16 bit modes on ARM and x86 devices. It looks to run quit speedily. The "examples/primitives.pl" in the CPAN package has also been modified to exploit double buffering for 16 bit modes. Let me know how it goes. Rich On 7/8/2016 12:12 PM, Erik Olson via RT wrote: Show quoted text

> Queue: Graphics-Framebuffer > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > Thanks Rich, > > I turned off acceleration as you suggested and the output changed slightly > - see the attached picture. The overlapping sections have the right color > now. > > Do you think the 16 bit Imager issue is responsible for not being about to > print "lower" in the screen as well? That is the one that is a killer for > me, but I have other parts of the project I can work on so life continues! > ;-) > > Thanks again! > > -Erik > > On Fri, Jul 8, 2016 at 10:02 AM, Richard Kelsch via RT < > bug-Graphics-Framebuffer@rt.cpan.org> wrote: >

>> <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >> >> Well, it's not exactly *ttf_print* that is the problem, but it does >> suffer from it. There's a color remapping issue with 16 bit mode I am >> working on currently. You see, "*Imager*" is all 32/24 bit only, and to >> make it work with 16 bit, I have to convert between color modes. If the >> code isn't exactly right, you can get artifacts. >> >> Most of my development has been on 32 bit mode output, but when I ran on >> a *Raspberry PI2* recently (which I use for 16 bit testing), I noticed >> these artifacts on all operations using *Imager*. I have recently >> accelerated the 32 bit to 16 bit and 32 bit to 16 bit conversion >> routines (in C code) to make these operations quick for folks with 16 >> bit TFT displays. However, some bugs have crept in. >> >> While I attempt to fix this, as a test, try nesting these commands >> around your ttf_print code to see if they "fix" the artifacting. Note, >> this will make ttf_print considerably slower, and this is only a test, >> as I will get you corrected code soon. I don't expect you to use this >> in your "production" code. I just want to see if it fixes things visually: >> >> $f->acceleration(0); >> $f->ttf_print....etc >> $f->acceleration(1); >> >> This will force the engine to use the Perl routines. Let me know if >> anything changes. Meanwhile I will get what issues I can find fixed on >> my end for you. >> >> Rich >> >> On 7/7/2016 11:35 PM, Erik Olson via RT wrote:

>>> Fri Jul 08 01:35:00 2016: Request 115967 was acted upon. >>> Transaction: Ticket created by snowrodeo@gmail.com >>> Queue: Graphics-Framebuffer >>> Subject: Bug with ttf_print >>> Broken in: (no value) >>> Severity: (no value) >>> Owner: Nobody >>> Requestors: snowrodeo@gmail.com >>> Status: new >>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >>> >>> >>> Hi again, >>> >>> I am seeing another bug(s) with ttf_print. >>> >>> 1) There seems to be an extra 'line' below the line printed. So if I

>> print

>>> at, say (40,40) with a height of 30, there seems to be a discolored area >>> below the printed line that seems to be about double the intended height >>> 2) When I intentionally overlap another line of text into this lower >>> region, the discoloration is worse (see the "Lin" in the picture) >>> 3) When the lower section is below the bottom of the frame buffer,

>> nothing

>>> prints. See the black hunk at the bottom >>> >>> Attached files: >>> 1) iPhone picture >>> 2) Code >>> 3) Dumper data >>> >>> Please let me know what I can do to help debug. >>> >>> Thanks, >>> >>> -Erik >>>

>> >>

Message body is not shown because sender requested not to inline it.

Sat Jul 09 22:59:39 2016 RKELSCH [...] cpan.org - Correspondence added 360 min

Method of how 16 bit modes are handled has been changed in 5.90+. Double-buffering for these modes are encouraged.

The bugs mentioned in the ticket only affected 16 bit modes.

Sat Jul 09 22:59:45 2016 RKELSCH [...] cpan.org - Status changed from 'open' to 'resolved'

Sat Jul 09 22:59:45 2016 RKELSCH [...] cpan.org - Taken

Fri Jul 15 15:44:02 2016 snowrodeo [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #115967] Bug with ttf_print
Date:	Fri, 15 Jul 2016 12:43:43 -0700
To:	bug-Graphics-Framebuffer [...] rt.cpan.org
From:	Erik Olson <snowrodeo [...] gmail.com>

Hi Richard, Just got back to the office today, sorry for the delay. I updated (via cpanm) the package and then ran the code as written from an ssh window into the Pi as I have been doing all along. Here is the output: erik@RPi3:~/sandbox/graphics$ ./ttf_print_bug3_fix_test.pl 963 Couldn't find an appropriate DIRECTORY for Inline to use. at /usr/local/share/perl/5.22.1/Graphics/Framebuffer/Accel.pm line 90. 946 You must be running from X-Windows, as I cannot detect the console! Stop, and re-run from a console (not console window) 946 You must be running from X-Windows, as I cannot detect the console! Stop, and re-run from a console (not console window) Can't locate object method "RGB8888_to_RGB565" via package "Graphics::Framebuffer" at /usr/local/share/perl/5.22.1/Graphics/Framebuffer/Accel.pm line 1104, <DATA> line 821. On Sat, Jul 9, 2016 at 7:55 PM, Richard Kelsch via RT < bug-Graphics-Framebuffer@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > I have uploaded a new version to CPAN (5.90). > > Attached is a new script for you to try. > > I have decided to implement double-buffering. The attached script uses it. > > It basically draws to a 32 bit virtual framebuffer and calls a new > method "blit_flip" to convert it to the real 16 bit framebuffer. > > Pay careful attention to how both are created. Also, due to the fact > RAM buffering is used, "FILE_MODE" is ineffective. It's best if you > leave that off (it will be going away eventually anyway). > > I did testing here with my 16 bit modes on ARM and x86 devices. It > looks to run quit speedily. > > The "examples/primitives.pl" in the CPAN package has also been modified > to exploit double buffering for 16 bit modes. > > Let me know how it goes. > > Rich > > On 7/8/2016 12:12 PM, Erik Olson via RT wrote:

> > Queue: Graphics-Framebuffer > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > > > Thanks Rich, > > > > I turned off acceleration as you suggested and the output changed

> slightly

> > - see the attached picture. The overlapping sections have the right

> color

> > now. > > > > Do you think the 16 bit Imager issue is responsible for not being about

> to

> > print "lower" in the screen as well? That is the one that is a killer

> for

> > me, but I have other parts of the project I can work on so life

> continues!

> > ;-) > > > > Thanks again! > > > > -Erik > > > > On Fri, Jul 8, 2016 at 10:02 AM, Richard Kelsch via RT < > > bug-Graphics-Framebuffer@rt.cpan.org> wrote: > >

> >> <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > >> > >> Well, it's not exactly *ttf_print* that is the problem, but it does > >> suffer from it. There's a color remapping issue with 16 bit mode I am > >> working on currently. You see, "*Imager*" is all 32/24 bit only, and to > >> make it work with 16 bit, I have to convert between color modes. If the > >> code isn't exactly right, you can get artifacts. > >> > >> Most of my development has been on 32 bit mode output, but when I ran on > >> a *Raspberry PI2* recently (which I use for 16 bit testing), I noticed > >> these artifacts on all operations using *Imager*. I have recently > >> accelerated the 32 bit to 16 bit and 32 bit to 16 bit conversion > >> routines (in C code) to make these operations quick for folks with 16 > >> bit TFT displays. However, some bugs have crept in. > >> > >> While I attempt to fix this, as a test, try nesting these commands > >> around your ttf_print code to see if they "fix" the artifacting. Note, > >> this will make ttf_print considerably slower, and this is only a test, > >> as I will get you corrected code soon. I don't expect you to use this > >> in your "production" code. I just want to see if it fixes things

> visually:

> >> > >> $f->acceleration(0); > >> $f->ttf_print....etc > >> $f->acceleration(1); > >> > >> This will force the engine to use the Perl routines. Let me know if > >> anything changes. Meanwhile I will get what issues I can find fixed on > >> my end for you. > >> > >> Rich > >> > >> On 7/7/2016 11:35 PM, Erik Olson via RT wrote:

> >>> Fri Jul 08 01:35:00 2016: Request 115967 was acted upon. > >>> Transaction: Ticket created by snowrodeo@gmail.com > >>> Queue: Graphics-Framebuffer > >>> Subject: Bug with ttf_print > >>> Broken in: (no value) > >>> Severity: (no value) > >>> Owner: Nobody > >>> Requestors: snowrodeo@gmail.com > >>> Status: new > >>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > >>> > >>> > >>> Hi again, > >>> > >>> I am seeing another bug(s) with ttf_print. > >>> > >>> 1) There seems to be an extra 'line' below the line printed. So if I

> >> print

> >>> at, say (40,40) with a height of 30, there seems to be a discolored

> area

> >>> below the printed line that seems to be about double the intended

> height

> >>> 2) When I intentionally overlap another line of text into this lower > >>> region, the discoloration is worse (see the "Lin" in the picture) > >>> 3) When the lower section is below the bottom of the frame buffer,

> >> nothing

> >>> prints. See the black hunk at the bottom > >>> > >>> Attached files: > >>> 1) iPhone picture > >>> 2) Code > >>> 3) Dumper data > >>> > >>> Please let me know what I can do to help debug. > >>> > >>> Thanks, > >>> > >>> -Erik > >>>

> >> > >>

> > >

Fri Jul 15 15:58:59 2016 rich [...] rk-internet.com - Correspondence added

Subject:	Re: [rt.cpan.org #115967] Bug with ttf_print
Date:	Fri, 15 Jul 2016 13:58:45 -0600
To:	bug-Graphics-Framebuffer [...] rt.cpan.org
From:	Richard Kelsch <rich [...] rk-internet.com>

Ouch, ouch, ouch, and ouch. OH!!! You're been using SSH.... hmmm... I hadn't considered that... hmmm... The "RGB8888_to_RGB565" error is a new one... Dang, and it all ran and looked so well. Haha, well, wishful thinking. I'll get it fixed. On 7/15/16 1:44 PM, Erik Olson via RT wrote: Show quoted text

> Queue: Graphics-Framebuffer > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > Hi Richard, > > Just got back to the office today, sorry for the delay. I updated (via > cpanm) the package and then ran the code as written from an ssh window into > the Pi as I have been doing all along. > > Here is the output: > > erik@RPi3:~/sandbox/graphics$ ./ttf_print_bug3_fix_test.pl > > 963 Couldn't find an appropriate DIRECTORY for Inline to use. > > at /usr/local/share/perl/5.22.1/Graphics/Framebuffer/Accel.pm line 90. > > 946 You must be running from X-Windows, as I cannot detect the console! > > Stop, and re-run from a console (not console window) > > 946 You must be running from X-Windows, as I cannot detect the console! > > Stop, and re-run from a console (not console window) > > Can't locate object method "RGB8888_to_RGB565" via package > "Graphics::Framebuffer" at > /usr/local/share/perl/5.22.1/Graphics/Framebuffer/Accel.pm line 1104, > <DATA> line 821. > > On Sat, Jul 9, 2016 at 7:55 PM, Richard Kelsch via RT < > bug-Graphics-Framebuffer@rt.cpan.org> wrote: >

>> <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >> >> I have uploaded a new version to CPAN (5.90). >> >> Attached is a new script for you to try. >> >> I have decided to implement double-buffering. The attached script uses it. >> >> It basically draws to a 32 bit virtual framebuffer and calls a new >> method "blit_flip" to convert it to the real 16 bit framebuffer. >> >> Pay careful attention to how both are created. Also, due to the fact >> RAM buffering is used, "FILE_MODE" is ineffective. It's best if you >> leave that off (it will be going away eventually anyway). >> >> I did testing here with my 16 bit modes on ARM and x86 devices. It >> looks to run quit speedily. >> >> The "examples/primitives.pl" in the CPAN package has also been modified >> to exploit double buffering for 16 bit modes. >> >> Let me know how it goes. >> >> Rich >> >> On 7/8/2016 12:12 PM, Erik Olson via RT wrote:

>>> Queue: Graphics-Framebuffer >>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >>> >>> Thanks Rich, >>> >>> I turned off acceleration as you suggested and the output changed

>> slightly

>>> - see the attached picture. The overlapping sections have the right

>> color

>>> now. >>> >>> Do you think the 16 bit Imager issue is responsible for not being about

>> to

>>> print "lower" in the screen as well? That is the one that is a killer

>> for

>>> me, but I have other parts of the project I can work on so life

>> continues!

>>> ;-) >>> >>> Thanks again! >>> >>> -Erik >>> >>> On Fri, Jul 8, 2016 at 10:02 AM, Richard Kelsch via RT < >>> bug-Graphics-Framebuffer@rt.cpan.org> wrote: >>>

>>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >>>> >>>> Well, it's not exactly *ttf_print* that is the problem, but it does >>>> suffer from it. There's a color remapping issue with 16 bit mode I am >>>> working on currently. You see, "*Imager*" is all 32/24 bit only, and to >>>> make it work with 16 bit, I have to convert between color modes. If the >>>> code isn't exactly right, you can get artifacts. >>>> >>>> Most of my development has been on 32 bit mode output, but when I ran on >>>> a *Raspberry PI2* recently (which I use for 16 bit testing), I noticed >>>> these artifacts on all operations using *Imager*. I have recently >>>> accelerated the 32 bit to 16 bit and 32 bit to 16 bit conversion >>>> routines (in C code) to make these operations quick for folks with 16 >>>> bit TFT displays. However, some bugs have crept in. >>>> >>>> While I attempt to fix this, as a test, try nesting these commands >>>> around your ttf_print code to see if they "fix" the artifacting. Note, >>>> this will make ttf_print considerably slower, and this is only a test, >>>> as I will get you corrected code soon. I don't expect you to use this >>>> in your "production" code. I just want to see if it fixes things

>> visually:

>>>> $f->acceleration(0); >>>> $f->ttf_print....etc >>>> $f->acceleration(1); >>>> >>>> This will force the engine to use the Perl routines. Let me know if >>>> anything changes. Meanwhile I will get what issues I can find fixed on >>>> my end for you. >>>> >>>> Rich >>>> >>>> On 7/7/2016 11:35 PM, Erik Olson via RT wrote:

>>>>> Fri Jul 08 01:35:00 2016: Request 115967 was acted upon. >>>>> Transaction: Ticket created by snowrodeo@gmail.com >>>>> Queue: Graphics-Framebuffer >>>>> Subject: Bug with ttf_print >>>>> Broken in: (no value) >>>>> Severity: (no value) >>>>> Owner: Nobody >>>>> Requestors: snowrodeo@gmail.com >>>>> Status: new >>>>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >>>>> >>>>> >>>>> Hi again, >>>>> >>>>> I am seeing another bug(s) with ttf_print. >>>>> >>>>> 1) There seems to be an extra 'line' below the line printed. So if I

>>>> print

>>>>> at, say (40,40) with a height of 30, there seems to be a discolored

>> area

>>>>> below the printed line that seems to be about double the intended

>> height

>>>>> 2) When I intentionally overlap another line of text into this lower >>>>> region, the discoloration is worse (see the "Lin" in the picture) >>>>> 3) When the lower section is below the bottom of the frame buffer,

>>>> nothing

>>>>> prints. See the black hunk at the bottom >>>>> >>>>> Attached files: >>>>> 1) iPhone picture >>>>> 2) Code >>>>> 3) Dumper data >>>>> >>>>> Please let me know what I can do to help debug. >>>>> >>>>> Thanks, >>>>> >>>>> -Erik >>>>>

>>>>

>> >>

Fri Jul 15 16:59:27 2016 snowrodeo [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #115967] Bug with ttf_print
Date:	Fri, 15 Jul 2016 13:59:08 -0700
To:	bug-Graphics-Framebuffer [...] rt.cpan.org
From:	Erik Olson <snowrodeo [...] gmail.com>

Let me know how I can help Show quoted text

> On Jul 15, 2016, at 12:59, Richard Kelsch via RT <bug-Graphics-Framebuffer@rt.cpan.org> wrote: > > <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > Ouch, ouch, ouch, and ouch. > > OH!!! You're been using SSH.... hmmm... I hadn't considered that... hmmm... > > The "RGB8888_to_RGB565" error is a new one... Dang, and it all ran and > looked so well. Haha, well, wishful thinking. I'll get it fixed. >

>> On 7/15/16 1:44 PM, Erik Olson via RT wrote: >> Queue: Graphics-Framebuffer >> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >> >> Hi Richard, >> >> Just got back to the office today, sorry for the delay. I updated (via >> cpanm) the package and then ran the code as written from an ssh window into >> the Pi as I have been doing all along. >> >> Here is the output: >> >> erik@RPi3:~/sandbox/graphics$ ./ttf_print_bug3_fix_test.pl >> >> 963 Couldn't find an appropriate DIRECTORY for Inline to use. >> >> at /usr/local/share/perl/5.22.1/Graphics/Framebuffer/Accel.pm line 90. >> >> 946 You must be running from X-Windows, as I cannot detect the console! >> >> Stop, and re-run from a console (not console window) >> >> 946 You must be running from X-Windows, as I cannot detect the console! >> >> Stop, and re-run from a console (not console window) >> >> Can't locate object method "RGB8888_to_RGB565" via package >> "Graphics::Framebuffer" at >> /usr/local/share/perl/5.22.1/Graphics/Framebuffer/Accel.pm line 1104, >> <DATA> line 821. >> >> On Sat, Jul 9, 2016 at 7:55 PM, Richard Kelsch via RT < >> bug-Graphics-Framebuffer@rt.cpan.org> wrote: >>

>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >>> >>> I have uploaded a new version to CPAN (5.90). >>> >>> Attached is a new script for you to try. >>> >>> I have decided to implement double-buffering. The attached script uses it. >>> >>> It basically draws to a 32 bit virtual framebuffer and calls a new >>> method "blit_flip" to convert it to the real 16 bit framebuffer. >>> >>> Pay careful attention to how both are created. Also, due to the fact >>> RAM buffering is used, "FILE_MODE" is ineffective. It's best if you >>> leave that off (it will be going away eventually anyway). >>> >>> I did testing here with my 16 bit modes on ARM and x86 devices. It >>> looks to run quit speedily. >>> >>> The "examples/primitives.pl" in the CPAN package has also been modified >>> to exploit double buffering for 16 bit modes. >>> >>> Let me know how it goes. >>> >>> Rich >>>

>>>> On 7/8/2016 12:12 PM, Erik Olson via RT wrote: >>>> Queue: Graphics-Framebuffer >>>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >>>> >>>> Thanks Rich, >>>> >>>> I turned off acceleration as you suggested and the output changed

>>> slightly

>>>> - see the attached picture. The overlapping sections have the right

>>> color

>>>> now. >>>> >>>> Do you think the 16 bit Imager issue is responsible for not being about

>>> to

>>>> print "lower" in the screen as well? That is the one that is a killer

>>> for

>>>> me, but I have other parts of the project I can work on so life

>>> continues!

>>>> ;-) >>>> >>>> Thanks again! >>>> >>>> -Erik >>>> >>>> On Fri, Jul 8, 2016 at 10:02 AM, Richard Kelsch via RT < >>>> bug-Graphics-Framebuffer@rt.cpan.org> wrote: >>>>

>>>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >>>>> >>>>> Well, it's not exactly *ttf_print* that is the problem, but it does >>>>> suffer from it. There's a color remapping issue with 16 bit mode I am >>>>> working on currently. You see, "*Imager*" is all 32/24 bit only, and to >>>>> make it work with 16 bit, I have to convert between color modes. If the >>>>> code isn't exactly right, you can get artifacts. >>>>> >>>>> Most of my development has been on 32 bit mode output, but when I ran on >>>>> a *Raspberry PI2* recently (which I use for 16 bit testing), I noticed >>>>> these artifacts on all operations using *Imager*. I have recently >>>>> accelerated the 32 bit to 16 bit and 32 bit to 16 bit conversion >>>>> routines (in C code) to make these operations quick for folks with 16 >>>>> bit TFT displays. However, some bugs have crept in. >>>>> >>>>> While I attempt to fix this, as a test, try nesting these commands >>>>> around your ttf_print code to see if they "fix" the artifacting. Note, >>>>> this will make ttf_print considerably slower, and this is only a test, >>>>> as I will get you corrected code soon. I don't expect you to use this >>>>> in your "production" code. I just want to see if it fixes things

>>> visually:

>>>>> $f->acceleration(0); >>>>> $f->ttf_print....etc >>>>> $f->acceleration(1); >>>>> >>>>> This will force the engine to use the Perl routines. Let me know if >>>>> anything changes. Meanwhile I will get what issues I can find fixed on >>>>> my end for you. >>>>> >>>>> Rich >>>>>

>>>>>> On 7/7/2016 11:35 PM, Erik Olson via RT wrote: >>>>>> Fri Jul 08 01:35:00 2016: Request 115967 was acted upon. >>>>>> Transaction: Ticket created by snowrodeo@gmail.com >>>>>> Queue: Graphics-Framebuffer >>>>>> Subject: Bug with ttf_print >>>>>> Broken in: (no value) >>>>>> Severity: (no value) >>>>>> Owner: Nobody >>>>>> Requestors: snowrodeo@gmail.com >>>>>> Status: new >>>>>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > >>>>>> >>>>>> >>>>>> Hi again, >>>>>> >>>>>> I am seeing another bug(s) with ttf_print. >>>>>> >>>>>> 1) There seems to be an extra 'line' below the line printed. So if I

>>>>> print

>>>>>> at, say (40,40) with a height of 30, there seems to be a discolored

>>> area

>>>>>> below the printed line that seems to be about double the intended

>>> height

>>>>>> 2) When I intentionally overlap another line of text into this lower >>>>>> region, the discoloration is worse (see the "Lin" in the picture) >>>>>> 3) When the lower section is below the bottom of the frame buffer,

>>>>> nothing

>>>>>> prints. See the black hunk at the bottom >>>>>> >>>>>> Attached files: >>>>>> 1) iPhone picture >>>>>> 2) Code >>>>>> 3) Dumper data >>>>>> >>>>>> Please let me know what I can do to help debug. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Erik

> >

Sat Jul 16 17:25:22 2016 RKELSCH [...] cpan.org - Correspondence added

Message body is not shown because it is too large.

Sun Jul 17 10:33:13 2016 snowrodeo [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #115967] Bug with ttf_print
Date:	Sun, 17 Jul 2016 07:33:00 -0700
To:	bug-Graphics-Framebuffer [...] rt.cpan.org
From:	Erik Olson <snowrodeo [...] gmail.com>

Hi Richard, It looks like this version works! I will be out for again for the next week so the rest of the tests will need to wait, but THANK YOU once again!! -Erik FWIW, I am writing a 'button press' system on top of your package that uses the Linux joystick interface for a touchscreen. The ultimate goal is to have a very simple touchscreen driven UI for my project. My perl is very simple and poorly written, but I would be happy to 'contribute' it back to your package if you would be interested. I know it isn't a perfect fit because of the touchscreen, but folks like Adafruit seem to sell a bunch of these for RPi projects. On Sat, Jul 16, 2016 at 2:25 PM, Richard Kelsch via RT < bug-Graphics-Framebuffer@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > Here's what is going on. It's not as bad as it looks. > > First of all, 5.91 should fix what I explain below: > > The problem wasn't the module, but the test script (usually is). It was > trying > to force the location of where the compiled "_Inline" folder location is. > Since > it couldn't do that, the compile failed, and when the compile failed, all > hell > broke loose and the subs import got borked (hence the missing method > error). > > Bypassing the test would actually have worked fine. > > While installing via the "cpan" script can be handy, it can also be > bothersome, > and here's where it is bothersome. A simple > > force install Graphics::Framebuffer > > would have installed it just fine. This would have told it to ignore the > "test" > results and install it anyway. > > 5.91 removes the bizarre behavior in the test stage, and should work with a > cpan install, and even the test stage now. > > I have tested the method you use to install and run the module (SSH), and > it > works fine. You should still be able to do it (as long as X-Windows is not > showing on a display). > > On Fri Jul 15 14:59:27 2016, snowrodeo@gmail.com wrote:

> > Let me know how I can help > >

> > > On Jul 15, 2016, at 12:59, Richard Kelsch via RT <bug-Graphics- > > > Framebuffer@rt.cpan.org> wrote: > > > > > > <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > > > > > Ouch, ouch, ouch, and ouch. > > > > > > OH!!! You're been using SSH.... hmmm... I hadn't considered that... > > > hmmm... > > > > > > The "RGB8888_to_RGB565" error is a new one... Dang, and it all ran > > > and > > > looked so well. Haha, well, wishful thinking. I'll get it fixed. > > >

> > >> On 7/15/16 1:44 PM, Erik Olson via RT wrote: > > >> Queue: Graphics-Framebuffer > > >> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > >> > > >> Hi Richard, > > >> > > >> Just got back to the office today, sorry for the delay. I updated > > >> (via > > >> cpanm) the package and then ran the code as written from an ssh > > >> window into > > >> the Pi as I have been doing all along. > > >> > > >> Here is the output: > > >> > > >> erik@RPi3:~/sandbox/graphics$ ./ttf_print_bug3_fix_test.pl > > >> > > >> 963 Couldn't find an appropriate DIRECTORY for Inline to use. > > >> > > >> at /usr/local/share/perl/5.22.1/Graphics/Framebuffer/Accel.pm line > > >> 90. > > >> > > >> 946 You must be running from X-Windows, as I cannot detect the > > >> console! > > >> > > >> Stop, and re-run from a console (not console window) > > >> > > >> 946 You must be running from X-Windows, as I cannot detect the > > >> console! > > >> > > >> Stop, and re-run from a console (not console window) > > >> > > >> Can't locate object method "RGB8888_to_RGB565" via package > > >> "Graphics::Framebuffer" at > > >> /usr/local/share/perl/5.22.1/Graphics/Framebuffer/Accel.pm line > > >> 1104, > > >> <DATA> line 821. > > >> > > >> On Sat, Jul 9, 2016 at 7:55 PM, Richard Kelsch via RT < > > >> bug-Graphics-Framebuffer@rt.cpan.org> wrote: > > >>

> > >>> <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > >>> > > >>> I have uploaded a new version to CPAN (5.90). > > >>> > > >>> Attached is a new script for you to try. > > >>> > > >>> I have decided to implement double-buffering. The attached script > > >>> uses it. > > >>> > > >>> It basically draws to a 32 bit virtual framebuffer and calls a new > > >>> method "blit_flip" to convert it to the real 16 bit framebuffer. > > >>> > > >>> Pay careful attention to how both are created. Also, due to the > > >>> fact > > >>> RAM buffering is used, "FILE_MODE" is ineffective. It's best if > > >>> you > > >>> leave that off (it will be going away eventually anyway). > > >>> > > >>> I did testing here with my 16 bit modes on ARM and x86 devices. It > > >>> looks to run quit speedily. > > >>> > > >>> The "examples/primitives.pl" in the CPAN package has also been > > >>> modified > > >>> to exploit double buffering for 16 bit modes. > > >>> > > >>> Let me know how it goes. > > >>> > > >>> Rich > > >>>

> > >>>> On 7/8/2016 12:12 PM, Erik Olson via RT wrote: > > >>>> Queue: Graphics-Framebuffer > > >>>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > >>>> > > >>>> Thanks Rich, > > >>>> > > >>>> I turned off acceleration as you suggested and the output changed

> > >>> slightly

> > >>>> - see the attached picture. The overlapping sections have the > > >>>> right

> > >>> color

> > >>>> now. > > >>>> > > >>>> Do you think the 16 bit Imager issue is responsible for not being > > >>>> about

> > >>> to

> > >>>> print "lower" in the screen as well? That is the one that is a > > >>>> killer

> > >>> for

> > >>>> me, but I have other parts of the project I can work on so life

> > >>> continues!

> > >>>> ;-) > > >>>> > > >>>> Thanks again! > > >>>> > > >>>> -Erik > > >>>> > > >>>> On Fri, Jul 8, 2016 at 10:02 AM, Richard Kelsch via RT < > > >>>> bug-Graphics-Framebuffer@rt.cpan.org> wrote: > > >>>>

> > >>>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=115967 > > > >>>>> > > >>>>> Well, it's not exactly *ttf_print* that is the problem, but it > > >>>>> does > > >>>>> suffer from it. There's a color remapping issue with 16 bit mode > > >>>>> I am > > >>>>> working on currently. You see, "*Imager*" is all 32/24 bit only, > > >>>>> and to > > >>>>> make it work with 16 bit, I have to convert between color modes. > > >>>>> If the > > >>>>> code isn't exactly right, you can get artifacts. > > >>>>> > > >>>>> Most of my development has been on 32 bit mode output, but when I > > >>>>> ran on > > >>>>> a *Raspberry PI2* recently (which I use for 16 bit testing), I > > >>>>> noticed > > >>>>> these artifacts on all operations using *Imager*. I have recently > > >>>>> accelerated the 32 bit to 16 bit and 32 bit to 16 bit conversion > > >>>>> routines (in C code) to make these operations quick for folks > > >>>>> with 16 > > >>>>> bit TFT displays. However, some bugs have crept in. > > >>>>> > > >>>>> While I attempt to fix this, as a test, try nesting these > > >>>>> commands > > >>>>> around your ttf_print code to see if they "fix" the artifacting. > > >>>>> Note, > > >>>>> this will make ttf_print considerably slower, and this is only a > > >>>>> test, > > >>>>> as I will get you corrected code soon. I don't expect you to use > > >>>>> this > > >>>>> in your "production" code. I just want to see if it fixes things

> > >>> visually:

> > >>>>> $f->acceleration(0); > > >>>>> $f->ttf_print....etc > > >>>>> $f->acceleration(1); > > >>>>> > > >>>>> This will force the engine to use the Perl routines. Let me know > > >>>>> if > > >>>>> anything changes. Meanwhile I will get what issues I can find > > >>>>> fixed on > > >>>>> my end for you. > > >>>>> > > >>>>> Rich > > >>>>>

> > >>>>>> On 7/7/2016 11:35 PM, Erik Olson via RT wrote: > > >>>>>> Fri Jul 08 01:35:00 2016: Request 115967 was acted upon. > > >>>>>> Transaction: Ticket created by snowrodeo@gmail.com > > >>>>>> Queue: Graphics-Framebuffer > > >>>>>> Subject: Bug with ttf_print > > >>>>>> Broken in: (no value) > > >>>>>> Severity: (no value) > > >>>>>> Owner: Nobody > > >>>>>> Requestors: snowrodeo@gmail.com > > >>>>>> Status: new > > >>>>>> Ticket <URL: > > >>>>>> https://rt.cpan.org/Ticket/Display.html?id=115967 > > > >>>>>> > > >>>>>> > > >>>>>> Hi again, > > >>>>>> > > >>>>>> I am seeing another bug(s) with ttf_print. > > >>>>>> > > >>>>>> 1) There seems to be an extra 'line' below the line printed. So > > >>>>>> if I

> > >>>>> print

> > >>>>>> at, say (40,40) with a height of 30, there seems to be a > > >>>>>> discolored

> > >>> area

> > >>>>>> below the printed line that seems to be about double the > > >>>>>> intended

> > >>> height

> > >>>>>> 2) When I intentionally overlap another line of text into this > > >>>>>> lower > > >>>>>> region, the discoloration is worse (see the "Lin" in the > > >>>>>> picture) > > >>>>>> 3) When the lower section is below the bottom of the frame > > >>>>>> buffer,

> > >>>>> nothing

> > >>>>>> prints. See the black hunk at the bottom > > >>>>>> > > >>>>>> Attached files: > > >>>>>> 1) iPhone picture > > >>>>>> 2) Code > > >>>>>> 3) Dumper data > > >>>>>> > > >>>>>> Please let me know what I can do to help debug. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> > > >>>>>> -Erik

> > > > > >

> >

Message body is not shown because it is too large.

Bug #115967 for Graphics-Framebuffer: Bug with ttf_print