Probably due to the inline window resize procedure and a bit from the dynamic object managment. Try only with a different lib than the 'window' libs to be sure..
No, the resize window handler is now changed to allow to use the #PB_Event_WindowResize constant in the main loop, without have to setup a callback. And this handler is a bit big (3 kb), but I think it worth it. So yes, the Window lib has grown of 3 kb.
Fred wrote:No, the resize window handler is now changed to allow to use the #PB_Event_WindowResize constant in the main loop, without have to setup a callback. And this handler is a bit big (3 kb), but I think it worth it. So yes, the Window lib has grown of 3 kb.
The window lib has grown exactly 3584 bytes by this. What are 3584 bytes in a GUI application??
I think you guys really should stop being so fanatic about the sizes, and think a little more realistic.
The window lib has grown exactly 3584 bytes by this. What are 3584 bytes in a GUI application??
I think you guys really should stop being so fanatic about the sizes, and think a little more realistic.
Timo
3 k on THIS lib, and tomorrow another 4 k in other... I just suggest that some libs could be splited to keep small size, don't see why is fanatism!
The principle to just compile what is needed is good i think!
i agree with dare here,
if it adds good things then who cares what it adds to the executes
size doesn't all matter to computers these days when it comes to bytes and kilobytes it not like everyone is on 486's with 5meg of harddrive space