Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » U++ community news and announcements » Major Draw refactoring
Re: Major Draw refactoring [message #22461 is a reply to message #22459] Fri, 17 July 2009 13:34 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3248
Registered: August 2008
Senior Veteran
Hello Mirek

Now class Draw has not IsDrawing() method.
IsDrawing() is used in Bazaar package Scatter.

How has it to be done with new Draw ?

Best regards
Koldo


Best regards
Iñaki
Re: Major Draw refactoring [message #22463 is a reply to message #22461] Fri, 17 July 2009 14:18 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13050
Registered: November 2005
Ultimate Member
koldo wrote on Fri, 17 July 2009 07:34

Hello Mirek

Now class Draw has not IsDrawing() method.
IsDrawing() is used in Bazaar package Scatter.

How has it to be done with new Draw ?

Best regards
Koldo


Well, the first question is whether you really need to know if Draw is DrawingDraw...

If yes, you can use dynamic_cast<DrawingDraw *>.

If that is not enough, we can consider moving IsDrawing. But I was trying to simplify the interface as much as possible...

Mirek
Re: Major Draw refactoring [message #22464 is a reply to message #22456] Fri, 17 July 2009 14:19 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13050
Registered: November 2005
Ultimate Member
ncompoop wrote on Fri, 17 July 2009 05:01

Just an addition to nixnixnix Vista woes. I appears that UPP can't find any fonts, only STDFONT is available, which is not a pretty sight indeed.

The problem started somewhere after svn.1415.




Yes, correct. It should now be fixed.

Hopefully, these turbulent times will be over soon Smile

Mirek
Re: Major Draw refactoring [message #22467 is a reply to message #22463] Fri, 17 July 2009 17:24 Go to previous messageGo to next message
Novo is currently online  Novo
Messages: 1139
Registered: December 2006
Senior Contributor
luzr wrote on Fri, 17 July 2009 08:18



If yes, you can use dynamic_cast<DrawingDraw *>.




Is it really necessary to use RTTI with UPP? It makes code bigger and used only at very limited number of places in UPP. Avoiding RTTI (and exceptions) would attract small platform users.

Sorry for the offtopic.


Regards,
Novo
Re: Major Draw refactoring [message #22469 is a reply to message #22467] Fri, 17 July 2009 17:43 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13050
Registered: November 2005
Ultimate Member
Novo wrote on Fri, 17 July 2009 11:24

luzr wrote on Fri, 17 July 2009 08:18



If yes, you can use dynamic_cast<DrawingDraw *>.




Is it really necessary to use RTTI with UPP? It makes code bigger and used only at very limited number of places in UPP. Avoiding RTTI (and exceptions) would attract small platform users.

Sorry for the offtopic.


RTTI is valid part of C++ standard and while minor feature, it has a nice ability to automatically provide solution to problems similiar to this one.

I do not believe that it makes code *significantly* bigger. There is not that much to store in memory in order to support RTTI (AFAIK).

Mirek
Re: Major Draw refactoring [message #22474 is a reply to message #22469] Fri, 17 July 2009 23:54 Go to previous messageGo to next message
Novo is currently online  Novo
Messages: 1139
Registered: December 2006
Senior Contributor
luzr wrote on Fri, 17 July 2009 11:43

Novo wrote on Fri, 17 July 2009 11:24

luzr wrote on Fri, 17 July 2009 08:18



If yes, you can use dynamic_cast<DrawingDraw *>.




Is it really necessary to use RTTI with UPP? It makes code bigger and used only at very limited number of places in UPP. Avoiding RTTI (and exceptions) would attract small platform users.

Sorry for the offtopic.


RTTI is valid part of C++ standard and while minor feature, it has a nice ability to automatically provide solution to problems similiar to this one.

I do not believe that it makes code *significantly* bigger. There is not that much to store in memory in order to support RTTI (AFAIK).

Mirek


I couldn’t find a tool, which calculates size of RTTI info in an executable. Visually TheIDE has ~5% of overhead because of RTTI (you can see at least mangled names in data sections). This percentage depends on size of class’ names and complexity of templates. STL and BOOST would give much bigger overhead.

During research of this topic I found a very interesting article: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedb ack.aspx?FeedbackID=471325

It looks like Visual C++ puts RTTI info into Read/Write segment. That doesn’t increase size of executable but increases run-time memory consumption. This explains why all windows applications require so much memory Wink.

Probably, MINGW is not that bad after all. Smile

TheIDE according to dumpbin:

  Summary

      142000 .data
      172000 .rdata
        1000 .rsrc
      257000 .text

SECTION HEADER #3
   .data name
  1412FC virtual size
  3CA000 virtual address (007CA000 to 0090B2FB)
   34000 size of raw data
  3CA000 file pointer to raw data (003CA000 to 003FDFFF)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
C0000040 flags
         Initialized Data
         Read Write

  Summary

      142000 .data



The ".data" segment is 13% of the ".text" segment. Not all ".data" is RTTI but still ...
And for some reason it requires 55% of ".text"'s size at run-time.

Any way, small device guys always compile with RTTI disabled.


Regards,
Novo
Re: Major Draw refactoring [message #22476 is a reply to message #22474] Sat, 18 July 2009 02:12 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13050
Registered: November 2005
Ultimate Member
Novo wrote on Fri, 17 July 2009 17:54



The ".data" segment is 13% of the ".text" segment. Not all ".data" is RTTI but still ...
And for some reason it requires 55% of ".text"'s size at run-time.

Any way, small device guys always compile with RTTI disabled.



IMO, most of ".data" is .iml...

Mirek
Re: Major Draw refactoring [message #22478 is a reply to message #22476] Sat, 18 July 2009 02:55 Go to previous messageGo to next message
Novo is currently online  Novo
Messages: 1139
Registered: December 2006
Senior Contributor
luzr wrote on Fri, 17 July 2009 20:12

Novo wrote on Fri, 17 July 2009 17:54



The ".data" segment is 13% of the ".text" segment. Not all ".data" is RTTI but still ...
And for some reason it requires 55% of ".text"'s size at run-time.

Any way, small device guys always compile with RTTI disabled.



IMO, most of ".data" is .iml...

Mirek


IMO, that should go in ".rdata" because it is read-only.


Regards,
Novo

[Updated on: Sat, 18 July 2009 02:58]

Report message to a moderator

Re: Major Draw refactoring [message #22493 is a reply to message #22478] Sun, 19 July 2009 12:58 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
Novo wrote on Sat, 18 July 2009 03:55

luzr wrote on Fri, 17 July 2009 20:12

Novo wrote on Fri, 17 July 2009 17:54



The ".data" segment is 13% of the ".text" segment. Not all ".data" is RTTI but still ...
And for some reason it requires 55% of ".text"'s size at run-time.

Any way, small device guys always compile with RTTI disabled.



IMO, most of ".data" is .iml...

Mirek


IMO, that should go in ".rdata" because it is read-only.

I think it's not read-only because you can modify the content of an .iml file, replacing an image from Iml class with your own image.
Re: Major Draw refactoring [message #22494 is a reply to message #22493] Sun, 19 July 2009 15:17 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13050
Registered: November 2005
Ultimate Member
andrei_natanael wrote on Sun, 19 July 2009 06:58

Novo wrote on Sat, 18 July 2009 03:55

luzr wrote on Fri, 17 July 2009 20:12

Novo wrote on Fri, 17 July 2009 17:54



The ".data" segment is 13% of the ".text" segment. Not all ".data" is RTTI but still ...
And for some reason it requires 55% of ".text"'s size at run-time.

Any way, small device guys always compile with RTTI disabled.



IMO, most of ".data" is .iml...

Mirek


IMO, that should go in ".rdata" because it is read-only.

I think it's not read-only because you can modify the content of an .iml file, replacing an image from Iml class with your own image.


Actually, that might be unrelated (original data are still in memory, just pointers get updated).

Mirek
Re: Major Draw refactoring [message #22744 is a reply to message #22494] Mon, 10 August 2009 20:46 Go to previous messageGo to next message
nixnixnix is currently offline  nixnixnix
Messages: 415
Registered: February 2007
Location: Kelowna, British Columbia
Senior Member
Hey Mirek,

Just a quick note to say thanks for fixing the Vista issues. Everything looks good from where I am.

Cheers,

Nick

[Updated on: Tue, 11 August 2009 17:50]

Report message to a moderator

Re: Major Draw refactoring [message #22756 is a reply to message #22744] Tue, 11 August 2009 17:49 Go to previous messageGo to next message
nixnixnix is currently offline  nixnixnix
Messages: 415
Registered: February 2007
Location: Kelowna, British Columbia
Senior Member
Hey Mirek,

You moved some of the ImageDraw code to CtrlCore! You tried to trick me but I caught you! Smile

N
Re: Major Draw refactoring [message #22757 is a reply to message #22756] Tue, 11 August 2009 18:25 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13050
Registered: November 2005
Ultimate Member
nixnixnix wrote on Tue, 11 August 2009 11:49

Hey Mirek,

You moved some of the ImageDraw code to CtrlCore! You tried to trick me but I caught you! Smile

N


Well, that was necessary to achieve the basic goal: Make Draw idependent from platform GUI.

There is now, BTW, new class ImageAnyDraw, which would use either ImagePainter (with priority) or ImageDraw (which I have typedefed to SystemImageDraw too, just to make it more clear). With ImagePainter variants, no GDI or X11 calls are necessary to create the Image.

Mirek
Re: Major Draw refactoring [message #22760 is a reply to message #22757] Tue, 11 August 2009 20:20 Go to previous message
nixnixnix is currently offline  nixnixnix
Messages: 415
Registered: February 2007
Location: Kelowna, British Columbia
Senior Member
I see. Good idea. You just need to add the Alpha() method then and I can convert to ImageAnyDraw and not include the CtrlCore package in my image processing console apps.

Cheers,

Nick
Previous Topic: sf.net tracker
Next Topic: U++ 1517 released
Goto Forum:
  


Current Time: Fri Jan 22 17:06:46 CET 2021

Total time taken to generate the page: 0.02592 seconds