The only ways to specify the pixels directly are via:
- consing up a BMP in memory
- using setPixels(...) api (which takes 32bit ARGB ints)

I apologize there there is no direct API that takes 565 values as input.

On Dec 2, 2008, at 4:41 AM, Koush wrote:


    { SkImageDecoder_GIF_Factory,   SkImageDecoder::kGIF_Format },
    { SkImageDecoder_PNG_Factory,   SkImageDecoder::kPNG_Format },
    { SkImageDecoder_ICO_Factory,   SkImageDecoder::kICO_Format },
    { SkImageDecoder_WBMP_Factory,  SkImageDecoder::kWBMP_Format },
    { SkImageDecoder_BMP_Factory,   SkImageDecoder::kBMP_Format },
    // jpeg must be last, as it doesn't have a good sniffer yet
    { SkImageDecoder_JPEG_Factory,  SkImageDecoder::kJPEG_Format }

That's the list of formats supported by SKImageDecoder. Another
possible solution is to dummy up a BMP header (pretty trivial) and
then decode the bytes. But that is still a hack...

On Dec 2, 1:15 am, Christine <[EMAIL PROTECTED]> wrote:
> As John says, why don't you use BitmapFactory.decodeByteArray?
>
> On Dec 2, 10:03 am, Koush <[EMAIL PROTECTED]> wrote:
>
>> Also, the Bitmap class internally (in the C++ JNI atleast) supports
>> the all familiar lockPixels and unlockPixels methods, which allows
>> direct access to the byte buffer. I would suggest extending the Java
>> API to include those methods.
>
>> On Dec 2, 1:00 am, Koush <[EMAIL PROTECTED]> wrote:
>
>>> Dianne Hackborn: I am asking this in the context of how to create a
>>> screenshot application. Taking screenshots is not possible on the G1
>>> anyways, because reading from /dev/graphics/fb0 is only available to
>>> root and shell and not available to actual applications. Thus is  
>>> only
>>> works on hacked phones. So you're asking me to not do something,  
>>> when
>>> I'm well past the line of things I should not be doing. :)
>>> Incidentally, the inability to take a simple screenshot of what is  
>>> on
>>> your phone is a pretty significant oversight (you're not going to
>>> always be hooked up to a PC with the SDK/DDMS tool at your  
>>> disposal).
>
>>> John Spurlock: Decode byte array is for compressed byte arrays, such
>>> as PNGs and JPG.
>>> I am basically trying to copy directly into the pixel buffer.
>
>>> On Dec 1, 3:34 pm, John Spurlock <[EMAIL PROTECTED]> wrote:
>
>>>> BitmapFactory.decodeByteArray ?
>
>>>> http://code.google.com/android/reference/android/graphics/BitmapFacto 
>>>> ...
>
>>>> On Dec 1, 5:58 pm, Koush <[EMAIL PROTECTED]> wrote:
>
>>>>> I inspected Bitmap.cpp and found this function:
>
>>>>> static jboolean Bitmap_writeToParcel(JNIEnv* env, jobject,
>>>>>                                      const SkBitmap* bitmap,
>>>>>                                      jboolean isMutable, jobject
>>>>> parcel) {
>>>>>     if (parcel == NULL) {
>>>>>         SkDebugf("------- writeToParcel null parcel\n");
>>>>>         return false;
>>>>>     }
>
>>>>>     android::Parcel* p = android::parcelForJavaObject(env,  
>>>>> parcel);
>
>>>>>     p->writeInt32(isMutable);
>>>>>     p->writeInt32(bitmap->config());
>>>>>     p->writeInt32(bitmap->width());
>>>>>     p->writeInt32(bitmap->height());
>>>>>     p->writeInt32(bitmap->rowBytes());
>
>>>>>     if (bitmap->getConfig() == SkBitmap::kIndex8_Config) {
>>>>>         SkColorTable* ctable = bitmap->getColorTable();
>>>>>         if (ctable != NULL) {
>>>>>             int count = ctable->count();
>>>>>             p->writeInt32(count);
>>>>>             memcpy(p->writeInplace(count * sizeof(SkPMColor)),
>>>>>                    ctable->lockColors(), count *  
>>>>> sizeof(SkPMColor));
>>>>>             ctable->unlockColors(false);
>>>>>         } else {
>>>>>             p->writeInt32(0);   // indicate no ctable
>>>>>         }
>>>>>     }
>
>>>>>     size_t size = bitmap->getSize();
>>>>>     bitmap->lockPixels();
>>>>>     memcpy(p->writeInplace(size), bitmap->getPixels(), size);
>>>>>     bitmap->unlockPixels();
>>>>>     return true;
>
>>>>> }
>
>>>>> I can manually marshal a Bitmap parcel in the proper format, and  
>>>>> then
>>>>> append the custom byte buffer, and then use createFromParcel to  
>>>>> create
>>>>> a bitmap. That gets me indirect access to creating a bitmap  
>>>>> directly
>>>>> from a byte buffer. It's a bit of a hack obviously, and not  
>>>>> ideal. Is
>>>>> there a better way to do this?
>
>>>>> On Dec 1, 2:41 pm, Koush <[EMAIL PROTECTED]> wrote:
>
>>>>>> I'm trying to populate a create a bitmap from something other  
>>>>>> than an
>>>>>> RGBA int array.
>>>>>> However, the Bitmap creation overloads only take int arrays as  
>>>>>> inputs.
>
>>>>>> In particular, I have a byte buffer that is in the R5G6B5  
>>>>>> format that
>>>>>> I want to load directly into a bitmap. The format is supposedly
>>>>>> supported internally, but I can't figure out how to create the  
>>>>>> bitmap
>>>>>> without doing the R5G6B5 to A8R8G8B8 conversion first.



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to