From kde-devel  Sat Feb 10 11:12:46 2001
From: John Califf <jcaliff () compuzone ! net>
Date: Sat, 10 Feb 2001 11:12:46 +0000
To: kde-devel
Subject: Re: Need user feedback - PPC issues
X-MARC-Message: https://marc.info/?l=kde-devel&m=98180441626199
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--------------3246ADBF3A2EDEAE3C9EB7A9"

This is a multi-part message in MIME format.
--------------3246ADBF3A2EDEAE3C9EB7A9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ok.  I have looked again at the code in kis_image.cc and applied a fix
for the PPC display problem.  This has already been committed, a few
hours ago, so you can test again any time.  It may not completely fix
the issue, but may.  At the very least this needs to be done because the
old block of code made a direct equivalence between the binary contents
of a channel with a given offset in a QImage, in a definitely
little-endian fashion.  My changes instead extract the r, g, b and alpha
values from the channels, then use qRGb() and qRGba() to place the data
in the QImage at the given location.  This should be hardware
independent for 32 bit images.  This should only need to be done in one
place,  right before the image for each tile is converted to a QPixmap
for display on the canvas (view).  

Attached is a code fragment from the file kis_image.cc.  You or someone
else may want to look at the entire file,
/koffice/kimageshop/core/kis_image.cc.  However, testing on a PPC would
be much more helpful than speculation. Thanks very much for following
thru.  

John



Ian Reinhart Geiser wrote:
> 
> On Friday 09 February 2001 02:58, John Califf wrote:
> > Ian Reinhart Geiser wrote:
> > > I have been out all week but for screen shots of the latest CVS of
> > > krayon:
> > >
> > > http://linuxppc.org/home/geiseri/pic.php3?name=krayon_bug.png
> > >
> > > This shows the problem with alphablending.
> > >
> > > Everything else seems okay
> > > -ian reinhart geiser
> >
> > Thanks very much for this screenshot.  I'd say the problem is pretty
> > severe but now I can see how colors are rotated, (I can tell that the
> > version if quite recent from the icons,etc.) and I may be contacting you
> > later for testing some more if that's ok with you. I think there is just
> > one area of code that needs adjusting, but I may need help on this from
> > someone.
> >
> > Actually I tried to contact you several times after your originial bug
> > report but all my email got bounced, so I just gave up.
> >
> 
>         great, i love my mail server...
>         oh well, use this email addresss, but be warned i leave
>         the US on the 23rd and will not be online again for some
>         months.
> 
>         if you need anything before then let me know.
>         -ian reinhart geiser
>
--------------3246ADBF3A2EDEAE3C9EB7A9
Content-Type: text/plain; charset=us-ascii;
 name="fix.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="fix.txt"

// from kis_image.cc

void KisImage::convertTileToPixmap(KisLayer *lay, int tileNo, QPixmap *pix)
{
    /* Copy the composite image into a QImage so it can be 
    converted to a QPixmap.  Note: surprisingly it is not quicker 
    to render directly into a QImage probably due to the CPU cache, 
    it's also useless wrt (writing?) to other colour spaces  */
    
// too confusing - easier to use variables with color names
#if 0
    uchar *ptr0 = lay->channelMem(2, tileNo, 0, 0); // blue
    uchar *ptr1 = lay->channelMem(1, tileNo, 0, 0); // green
    uchar *ptr2 = lay->channelMem(0, tileNo, 0, 0); // red
#endif

    uchar *ptrBlue  = lay->channelMem(2, tileNo, 0, 0); // blue
    uchar *ptrGreen = lay->channelMem(1, tileNo, 0, 0); // green
    uchar *ptrRed   = lay->channelMem(0, tileNo, 0, 0); // red
    uchar *ptrAlpha = 0;
    
    if (m_cMode == cm_RGBA)    
         ptrAlpha = lay->channelMem(3, tileNo, 0, 0); // alpha
        
    for(int y = 0; y < TILE_SIZE; y++)
    {
// this directly equates what is in each channel to a QImage scanline
// offset backwards to front which hardcodes it to littlendian architecture
#if 0
        uchar *ptr = m_img.scanLine(y);
	    for(int x = TILE_SIZE; x; x--)
	    {
	        *ptr++ = *ptr0++; // blue
	        *ptr++ = *ptr1++; // green
	        *ptr++ = *ptr2++; // red
	        ptr++;  // alpha - ptr incremented, but value not used here
	    }
#endif

// this may be somewhat more inefficient for littlendian systems but 
// should also work with bigendian. It lets Qt determine the color values
// for each channel which automatically takes into account endianness for
// 32 bit images like these.  The intermediate variable can be removed
// later with the pointer increment taking place inside the qRgb( )
// phrase, I think, achieving the same performance.

        uchar iblue, ired, igreen, ialpha;
        
        uint *ptr = (uint *)m_img.scanLine(y);
	    for(int x = TILE_SIZE; x; x--)
	    {
            iblue   = *ptrBlue++;
            igreen  = *ptrGreen++;
            ired    = *ptrRed++;
                       
            if (m_cMode == cm_RGBA)
            {
                ialpha  = *ptrAlpha++;          

                // note - to duplicate (sortof) bigendian bug on littleendian
                // system, comment out next line and uncomment out the
                // one after - for testing only - john
                *ptr = qRgba(ired, igreen, iblue, ialpha);
                //*ptr = qRgb(ired, igreen, 255 - ialpha);
            }    
            else
            {    
                *ptr = qRgb(ired, igreen, iblue);
            }    
                
            ptr++; 
	    }
    }

    // Construct the relevant pixmap
    convertImageToPixmap(&m_img, pix);
}

--------------3246ADBF3A2EDEAE3C9EB7A9--

 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<