> I think g++ can be convinced to make the object 4 bytes in size and
> allocated on 4 byte boundaries but I am unsure about others.
>
> In general I agree it would be better to use a structure, so using your
> idea is good as long as we have proof that an array of them can be made
> equivalent to
One reason even on modern compilers to use U32 for the color is so that
images can be packed arrays of color objects. I believe on some 64 bit
compilers it will not make structures be less than 8 bytes. If this is
true then an implicit conversion from U32 to color is needed anyway.
I think g++
Matt,
Yes, OK, I know the Xcode project is the preferred build option on OSX, but I
always just use the Makefiles anyway.
Except that now it chokes on OSX...
Here's the tail of the build...
Compiling fl_images_core.cxx...
/usr/bin/ar cr ../lib/libfltk_images.a ...
make[1]: *** No rule to make t
> Generally I feel that a typedef is sufficient. It does not prevent
> misuse, but it makes the function prototypes clear. It also means that
> the user can type 0xaarrggbb directly into the code and it works. Qt is
> really annoying that I always have to look up the converter function.
I disagree
On 08/21/2011 10:40 AM, Evan Laforge wrote:
>> Creating its own type for color is ok with a typedef, but changing it from
>> an underlying uint32 wold be insanely inefficient, considering that a color
>> vaue is needed in every graphics call.
>
> typedef doesn't actually create a new type. A rea
> Creating its own type for color is ok with a typedef, but changing it from an
> underlying uint32 wold be insanely inefficient, considering that a color vaue
> is needed in every graphics call.
typedef doesn't actually create a new type. A real type should be
just as efficient as a number, an
On 21 Aug 2011, at 03:26, Evan Laforge wrote:
>> Pango's api pretty much takes entire blocks of text and a box to put
>> them into. It would replace a very high level drawing api in fltk.
>>
>> The OS/X and Windows systems should be rewritten to call their api at
>> this same high level.
>
> On
On 21 Aug 2011, at 03:00, Bill Spitzak wrote:
>
> Cairo/Pango are unfortunately not as fast as they should be.
You can say that again!
I had some code where we deliberately contrived to have either "fltk-native" or
Cairo as the back end renderer - sure the Cairo looked nicer (well, except on
On 21 Aug 2011, at 02:47, Bill Spitzak wrote:
> On 07/02/2011 12:44 AM, Georg Potthast wrote:
>> Thank you Matthias,
>>
>> I tried again and changed the first four entries in the Fl_Fontdesc
>> built_in_table[] from Helvetica to dejavu and that did work now.
>>
>> However, I think FLTK is free
On 21.08.2011, at 04:49, Bill Spitzak wrote:
> Another major change is to scrap the "@" language used in fltk2 (and not
> really existing in fltk1.3 at all) and instead go with a more html-like
> language.
Yes, that sounds like a good idea.
___
fltk
On 21.08.2011, at 05:02, Evan Laforge wrote:
> On Sat, Aug 20, 2011 at 7:41 PM, Bill Spitzak wrote:
>> For 3.0 (and probably 2.0 as well) I think it is very important that the
>> FLTK "color" unsigned value be changed so that it is 0xAARRGGBB, instead
>> of the 0xRRGGBBAA used in FLTK2.0 (and in
On 21.08.2011, at 04:23, Bill Spitzak wrote:
> My recommendation (somewhat done in fltk 2.0) is that fltk NEVER throws
> exceptions, and NEVER catches them.
>
> However it is allowed that callbacks throw exceptions. These should work
> and should cleanly return to the user code that catches th
12 matches
Mail list logo
