Page 1 of 1

What about the efficiency of wxWidgets' message map against MFC's?

Posted: Tue Mar 20, 2018 2:55 am
by Ronald
MFC uses a simple iteration to find message handler:

Code: Select all

const AFX_MSGMAP_ENTRY* AFXAPI
AfxFindMessageEntry(const AFX_MSGMAP_ENTRY* lpEntry,
    UINT nMsg, UINT nCode, UINT nID)
{
#if defined(_M_IX86) && !defined(_AFX_PORTABLE)
// 32-bit Intel 386/486 version.
……
#else  // _AFX_PORTABLE
    // C version of search routine
    while (lpEntry->nSig != AfxSig_end)
    {
        if (lpEntry->nMessage == nMsg && lpEntry->nCode == nCode &&
            nID >= lpEntry->nID && nID <= lpEntry->nLastID)
        {
            return lpEntry;
        }
        lpEntry++;
    }
    return NULL;    // not found
#endif  // _AFX_PORTABLE
}
It's not as good as "switch case".
What about wxWidgets?

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Tue Mar 20, 2018 2:54 pm
by ONEEYEMAN
Hi,
Library is open-source. Why not check it yourself? ;-)

Thank you.

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Tue Mar 20, 2018 3:32 pm
by eranon
Wow °O° Don't you think you're starting by studying the life of the ants before even looking at landscape... In reference to a previous thread you started, Ronald, just go with a first project, then profile and optimize what necessary for real -- afterward only. Upstream over-analysis is a good blocking point doing one never jumps in the action!

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Tue Mar 20, 2018 3:43 pm
by Ronald
ONEEYEMAN wrote:Hi,
Library is open-source. Why not check it yourself? ;-)

Thank you.
two steps in wxWidgets to find the handler:
1. search by event type
2. search by ID in the result of step 1
More efficient than MFC, but the framework about event handling is too complex.
I prefer "switch case", simple and efficient, the only problem is that it might become too long for human, but this problem can be solved, for example, by macro / function, even by GUI designer(edit event handler as flexible as possible in GUI designer, at last the GUI designer generates a big "switch case")

Code: Select all

bool wxEventHashTable::HandleEvent(wxEvent &event, wxEvtHandler *self)
{
    if (m_rebuildHash)
    {
        InitHashTable();
        m_rebuildHash = false;
    }

    if (!m_eventTypeTable)
        return false;

    // Find all entries for the given event type.
    wxEventType eventType = event.GetEventType();
    const EventTypeTablePointer eTTnode = m_eventTypeTable[eventType % m_size];
    if (eTTnode && eTTnode->eventType == eventType)
    {
        // Now start the search for an event handler
        // that can handle an event with the given ID.
        const wxEventTableEntryPointerArray&
            eventEntryTable = eTTnode->eventEntryTable;

        const size_t count = eventEntryTable.GetCount();
        for (size_t n = 0; n < count; n++)
        {
            const wxEventTableEntry& entry = *eventEntryTable[n];
            if ( wxEvtHandler::ProcessEventIfMatchesId(entry, self, event) )
                return true;
        }
    }

    return false;
}

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Tue Mar 20, 2018 4:12 pm
by Ronald
eranon wrote:Wow °O° Don't you think you're starting by studying the life of the ants before even looking at landscape... In reference to a previous thread you started, Ronald, just go with a first project, then profile and optimize what necessary for real -- afterward only. Upstream over-analysis is a good blocking point doing one never jumps in the action!
Top down method makes more sense. However, when I'm looking into the framework, it is too complex, many unexpected code for a function, some for workaround, some for hooking, not so relevant to the function itself. I think if I don't use the framework, I can make a procedure pure, without workaround (though encapsulated by framework), without hooking (it's true), it must be nice. I'll try and check the idea. :)

Indeed I think Bill Gates is smarter than the developers of MFC, so I'd like to program with Bill Gates, to see how he designs. :D

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Tue Mar 20, 2018 4:59 pm
by ONEEYEMAN
Hi,
I seriously doubt Mr. Gates is a good developer. He might just be a good marketer.
Anyway - any framework has its up- and down-sides.

Thank you.

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Tue Mar 20, 2018 5:28 pm
by doublemax
I didn't want to join this thread, because i didn't want to open another can of worms.

Just one thing: If you think the event dispatcher is inefficient, i dare you to single-step through a wxPaintDC constructor :)

You can write Windows applications in pure assembly. Why does nobody (in his right mind) do it? Because it's not worth the effort. You should look for performance bottlenecks where they matter.

Unless you're dissecting wxWidgets for academic purposes. In that case you'll probably find much more scary stuff in its source code.

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Tue Mar 20, 2018 6:13 pm
by Ronald
doublemax wrote:I didn't want to join this thread, because i didn't want to open another can of worms.

Just one thing: If you think the event dispatcher is inefficient, i dare you to single-step through a wxPaintDC constructor :)
The constructor seems too long, but each member makes sense, because the class name is about "Impl". Otherwise it's much harder to make every member make sense, including private ones.

Code: Select all

wxDCImpl::wxDCImpl( wxDC *owner )
        : m_window(NULL)
        , m_colour(wxColourDisplay())
        , m_ok(true)
        , m_clipping(false)
        , m_isInteractive(0)
        , m_isBBoxValid(false)
        , m_logicalOriginX(0), m_logicalOriginY(0)
        , m_deviceOriginX(0), m_deviceOriginY(0)
        , m_deviceLocalOriginX(0), m_deviceLocalOriginY(0)
        , m_logicalScaleX(1.0), m_logicalScaleY(1.0)
        , m_userScaleX(1.0), m_userScaleY(1.0)
        , m_scaleX(1.0), m_scaleY(1.0)
        , m_signX(1), m_signY(1)
        , m_contentScaleFactor(1)
        , m_minX(0), m_minY(0), m_maxX(0), m_maxY(0)
        , m_clipX1(0), m_clipY1(0), m_clipX2(0), m_clipY2(0)
        , m_logicalFunction(wxCOPY)
        , m_backgroundMode(wxBRUSHSTYLE_TRANSPARENT)
        , m_mappingMode(wxMM_TEXT)
        , m_pen()
        , m_brush()
        , m_backgroundBrush()
        , m_textForegroundColour(*wxBLACK)
        , m_textBackgroundColour(*wxWHITE)
        , m_font()
#if wxUSE_PALETTE
        , m_palette()
        , m_hasCustomPalette(false)
#endif // wxUSE_PALETTE
{
    m_owner = owner;

    m_mm_to_pix_x = (double)wxGetDisplaySize().GetWidth() /
                    (double)wxGetDisplaySizeMM().GetWidth();
    m_mm_to_pix_y = (double)wxGetDisplaySize().GetHeight() /
                    (double)wxGetDisplaySizeMM().GetHeight();

    ResetBoundingBox();
    ResetClipping();
}
You can write Windows applications in pure assembly. Why does nobody (in his right mind) do it? Because it's not worth the effort. You should look for performance bottlenecks where they matter.

Unless you're dissecting wxWidgets for academic purposes. In that case you'll probably find much more scary stuff in its source code.
Assembly is not natural for human. C is, and is good for procedure programming. C++ brings class, class really makes senses, it maps concept, but I think only a simple concept is easy to define, for example: desk, cat, sun. So I'd like only to define simple concept. Sense is always clearer in context (or in procedure) than in a static way. Procedure programming with simple classes seems good.

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Tue Mar 20, 2018 7:18 pm
by Ronald
ONEEYEMAN wrote:Hi,
I seriously doubt Mr. Gates is a good developer. He might just be a good marketer.
OK, he worked with many smartest people, for perfection. In fact, APIs are simple, efficient, native, integrity.
Anyway - any framework has its up- and down-sides.
Framework can really be very helpful, saving a lot of time.
wxWidgets is more efficient and native than Qt.
But I has been lost in the source code of wxWidgets or Qt. Native API can do everything, maybe it is not too hard to use, I must try.

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Tue Mar 20, 2018 9:55 pm
by eranon
Ronald wrote:Native API can do everything, maybe it is not too hard to use, I must try.
Native OS API can do everything about a single OS. More you go down in the layers, more it's specialized. So, wxWidgets is one single step above; the lowest layer for a native cross-platform API.

But, of course, if you prefer C to C++ because you're already proficient in C, the decision is already taken...

Just let come the void in your head and breathe. Take a step back to see the landscape, Ronald :mrgreen:

Code: Select all

memset(brain, '\0', mem_depth);

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Tue Mar 20, 2018 10:20 pm
by ONEEYEMAN
eranon,
He will need to do just that if he will do everything from scratch in pure-C. ;-)
Now Vadim said many times that wx API is not perfect and if he would, he would rewrite wx from scratch with the proper API in mind. Problem is - it will take a lot of time and money to do just that.
I'm sure Qt is the same, especially considering the way the program written in Qt is built and executed.
You might take a look at GTK+ itself as it is pure C, but then you will loose an abstraction which C++ provides.
Other than those 3 I don't know any library/framework which can do cross-platform development in a nice and efficient way.

@OP: Take a look here.
Or use Perl/Python.
Might be easier this way.

Thank you.

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Wed Mar 21, 2018 4:57 am
by Ronald
eranon wrote: But, of course, if you prefer C to C++ because you're already proficient in C, the decision is already taken...

Just let come the void in your head and breathe. Take a step back to see the landscape, Ronald :mrgreen:

Code: Select all

memset(brain, '\0', mem_depth);
ONEEYEMAN wrote: He will need to do just that if he will do everything from scratch in pure-C.
Now I'm sure something like QML / WPF / DialogBlocks / wxFormBuilder is the language for GUI, it can be translated to any native code by an interpreter (or compiler) potentially, as long as there is enough information. So writing compiler seems a hard way. #-o

Maybe some day, M$ will announce that WPF can generate native code for Linux / Android / iOS /Mac OS X, like .Net. I believe M$ is going this way. I think this way is good for open source, because it's easy to switch from one compiler to another. :)

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Wed Mar 21, 2018 11:24 am
by eranon
ONEEYEMAN wrote:Now Vadim said many times that wx API is not perfect and if he would, he would rewrite wx from scratch with the proper API in mind. Problem is - it will take a lot of time and money to do just that.
Yep, it's the overall issue of the life, ONEEYEMAN : There's no try, it's directly in reality... Well, but seeing the world context (everyone dreams to be a business man rather than developer, everyone celebrates Steve Jobs or Bill Gates but nobody knows there're just kids in front of Dennis Ritchie or Bjarne Stroustrup, everyone goes towards SaaS to display Hello on screen because it can be sold $1 per month), not sure better would be even noticed from outside. In French, we have an expression (sorry, no idea about the equivalent in English) : "Ce serait donner du caviar aux cochons !" :mrgreen: wxWidgets is perfect like this (I means far above what the world is able to appreciate) and in regular C++ where (as you stated) Qt is not pure C++ going through C++ compiler.
Ronald wrote: Now I'm sure something like QML / WPF / DialogBlocks / wxFormBuilder is the language for GUI, it can be translated to any native code by an interpreter (or compiler) potentially, as long as there is enough information. So writing compiler seems a hard way. #-o
Houla, you're mixing a lot of different concepts, Ronald:
- DialogBlocks and wxFormBuilder are not languages, but apps to generate wxWidgets-oriented C++ code about GUI. Here the language is C++.
- A compiler is not a converter of any language to any language, but is used to generate machine language (directly understandable by the microprocessor) or, at least (talking about pseudo-compiler), towards a lower level language (eg. bytecode about Java). If you convert wxWidgets-oriented C++ to WIN32-oriented C, it's not a compiler, but a "simple" (good luck) converter.
Ronald wrote:Maybe some day, M$ will announce that WPF can generate native code for Linux / Android / iOS /Mac OS X, like .Net. I believe M$ is going this way. I think this way is good for open source, because it's easy to switch from one compiler to another. :)
And Trump will dedicate the rest of his life to helping the world in the purest selflessness LOL Business men only do what is directly profitable for them -- DOT. You'll often see big company involved in open source with the idea to fork towards a proprietary branch later (eg. Apple and GCC), but rarely without a profit goal in background... And more, they often spend a lot of money to prevent any use that doesn't generate earn for them, not their neighbours (eg. You -- officially -- have to use a Mac for macOS, they wrote their boot and kernel to enforce this). Notice that my examples are focusing on Apple, but the same could exactly be said about every big company -- GAFAM bless you :mrgreen:

[This was my last message in this thread, but hoping -- I can't put more energy -- you understood the concept: Stop fantasizing -- said without any animosity, but to help you go forward -- and start to design and code for real ! You'll see, it's more difficult than talking, but far more rich inside]

Re: What about the efficiency of wxWidgets' message map against MFC's?

Posted: Wed Mar 21, 2018 11:53 am
by Ronald
eranon wrote:
ONEEYEMAN wrote:Now Vadim said many times that wx API is not perfect and if he would, he would rewrite wx from scratch with the proper API in mind. Problem is - it will take a lot of time and money to do just that.
Yep, it's the overall issue of the life, ONEEYEMAN : There's no try, it's directly in reality... Well, but seeing the world context (everyone dreams to be a business man rather than developer, everyone celebrates Steve Jobs or Bill Gates but nobody knows there're just kids in front of Dennis Ritchie or Bjarne Stroustrup, everyone goes towards SaaS to display Hello on screen because it can be sold $1 per month), not sure better would be even noticed from outside. In French, we have an expression (sorry, no idea about the equivalent in English) : "Ce serait donner du caviar aux cochons !" :mrgreen: wxWidgets is perfect like this (I means far above what the world is able to appreciate) and in regular C++ where (as you stated) Qt is not pure C++ going through C++ compiler.
Ronald wrote: Now I'm sure something like QML / WPF / DialogBlocks / wxFormBuilder is the language for GUI, it can be translated to any native code by an interpreter (or compiler) potentially, as long as there is enough information. So writing compiler seems a hard way. #-o
Houla, you're mixing a lot of different concepts, Ronald:
- DialogBlocks and wxFormBuilder are not languages, but apps to generate wxWidgets-oriented C++ code about GUI. Here the language is C++.
- A compiler is not a converter of any language to any language, but is used to generate machine language (directly understandable by the microprocessor) or, at least (talking about pseudo-compiler), towards a lower level language (eg. bytecode about Java). If you convert wxWidgets-oriented C++ to WIN32-oriented C, it's not a compiler, but a "simple" (good luck) converter.
Ronald wrote:Maybe some day, M$ will announce that WPF can generate native code for Linux / Android / iOS /Mac OS X, like .Net. I believe M$ is going this way. I think this way is good for open source, because it's easy to switch from one compiler to another. :)
And Trump will dedicate the rest of his life to helping the world in the purest selflessness LOL Business men only do what is directly profitable for them -- DOT. You'll often see big company involved in open source with the idea to fork towards a proprietary branch later (eg. Apple and GCC), but rarely without a profit goal in background... And more, they often spend a lot of money to prevent any use that doesn't generate earn for them, not their neighbours (eg. You -- officially -- have to use a Mac for macOS, they wrote their boot and kernel to enforce this). Notice that my examples are focusing on Apple, but the same could exactly be said about every big company -- GAFAM bless you :mrgreen:

[This was my last message in this thread, but hoping -- I can't put more energy -- you understood the concept: Stop fantasizing -- said without any animosity, but to help you go forward -- and start to design and code for real ! You'll see, it's more difficult than talking, but far more rich inside]
Thank you. I will use wxWidgets for productivity now. With the time wxWidgets saved for me, I'll learn and think about converter / compiler (wxFormBuilder is cool), the idea is simple, information is essential, express them in a most human friendly way (including GUI designer), then convert them to a most computer-friendly way (for example, a big switch is perfect when there are perfect tools to maintain it). In fact I've started learning compiler principle again yesterday.
Best regards.