Re: zinc performance - VxWorks

This is a discussion on Re: zinc performance - VxWorks ; On 18 Aug 2005, devgaonkar@gmail.com wrote: > Is zinc stable for real time system like vxWorks ? > Is there any other option for developing realtime gui ? That is not really a well formed question. It seems to ask ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: zinc performance

  1. Re: zinc performance

    On 18 Aug 2005, devgaonkar@gmail.com wrote:

    > Is zinc stable for real time system like vxWorks ?
    > Is there any other option for developing realtime gui ?


    That is not really a well formed question. It seems to ask for a
    general opinion. The stability of Zinc has nothing to do with "real
    time". The stability has to do with safety. Are you developing a
    safety critical app? Zinc itself is well behaved in relinquishing the
    CPU for higher priority tasks. That is really the only thing to do
    with "real time". Did you have "real time" information that is
    critical to be displayed?

    There are many other options for a realtime gui. See the FAQ and
    google.

    > I have had bad experience with zinc designer & its resource file
    > philosophy ! So I am mostly using code to design my GUI rather than
    > resource file.


    Zinc designer would be one reason to use Zinc in my opinion. The
    source code to Zinc designer is available on WindSurf. We had some
    problems with the designer crashing on NT. Once this was fixed, it
    worked well. It is also possible to change the default font in the
    designer source to match the font in your application. Laying out
    screens by coding is rather tedious; I don't know why you would throw
    away zdesign for this.

    Having the source for Zinc is very nice. However, it is a huge API
    and a lot of software. I would have reservations about the foot print
    of Zinc; it will approach 1MB and possibly more. You also realize
    that you have UGL (WindML or something) as well? UGL is fine for
    limit GUI. Do you have 100's of screens to design or just one or two?

    For instance, device configuration can be done with HTTP and form
    submission. If you have to configure the device through an embedded
    GUI, then Zinc is becoming a better choice. If you only have to
    display a single screen showing the status of different device inputs,
    then UGL (or some other GUI/graphics API) would be a better choice.

    hth,
    Bill Pringlemeir.

    --
    Windows programmer - every problem solved with a switch statement.

    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

  2. Re: zinc performance


    On 18 Aug 2005, devgaonkar@gmail.com wrote:

    >>> Is zinc stable for real time system like vxWorks ?
    >>> Is there any other option for developing realtime gui ?


    Bill Pringlemeir wrote:

    >> Zinc itself is well behaved in relinquishing the CPU for higher
    >> priority tasks. That is really the only thing to do with "real
    >> time". Did you have "real time" information that is critical to be
    >> displayed?


    On 19 Aug 2005, devgaonkar@gmail.com wrote:

    > I mean stability in terms of robustness,crashing etc. Our system is
    > supposed to work 24x7 without any crashes like we have in WINDOWS
    > OS.


    There are lots of memory allocation issues with Zinc that are not
    entirely clear from the API documents. However, I have found resource
    ownership confusing with several GUI's. I think this is a general
    problem. This is only a real concern if you are doing a custom
    widget. Ie, drawing things yourself. Other than these issues, there
    were few problems. I find it highly unlikely that any package you
    purchase will be bullet proof. Your choice might depend more on the
    features. Like do you need multi-language support? Kanji? Unicode?
    etc.

    >>> I have had bad experience with zinc designer & its resource file
    >>> philosophy ! So I am mostly using code to design my GUI rather
    >>> than resource file.


    >> We had some problems with the designer crashing on NT. Once this
    >> was fixed, it worked well.


    > I have had the same problem of designer crashing on windows 2000.
    > zdesign resource file was also used to get corrupted.
    > You said, u fixed the crashing problem. Did u mean by recompiling
    > zdesigner source code ?


    I think that the source code had been patched. However, you can
    contact WRS and get an updated executable. I think that it has to do
    with a particular type of GUI element in the zdesigner file (or this
    size of the designer file). There should be log files for the crash
    that would help WRS diagnose your problem.

    >> For instance, device configuration can be done with HTTP and form
    >> submission. If you have to configure the device through an
    >> embedded GUI, then Zinc is becoming a better choice. If you only
    >> have to display a single screen showing the status of different
    >> device inputs, then UGL (or some other GUI/graphics API) would be a
    >> better choice.


    > I did not understand above para. Can u please give me any pointers
    > to above information?


    These are different approaches to device configuration. For instance,
    suppose you are designing a router. You may wish to allow DHCP or a
    static network configuration. Some particular IP might be designated
    "DMZ". You may wish to enable/disable a DHCP server on the device,
    etc.

    This configuration will happen once. It is also quite clear that the
    user will have a PC. By providing an HTTP server on the device, you
    can configure it through a browser.

    Your device would have to have a network interface. You can also do
    the same thing with a serial port, usb, etc.

    The question is do you have to perform configuration via a device
    screen? In some cases you may have a display, but it is too small to
    display information.

    It sounds more like you are making an oscilliscope or something with
    similar GUI requirements. It may not be convenient to configure an
    oscilloscope by a separate PC each time you want to take a
    measurement. Now, if you have something for process control and the
    device configuration will remain static, then maybe this is a
    possibility.

    Configuration is often screen intensive. You must design many dialogs
    and interfaces to allow the user to do what they want. However, often
    most time will be spent on the main screen. If you can structure the
    product so that configuration is done by alternative means, UGL, etc
    might be an option. However, your disregard for memory requirements
    and your schedule demands seem to say that NRE is significant. This
    idea is probably not for you. Sometimes a little thought can save a
    lot of time.

    hth,
    Bill Pringlemeir

    --
    Truth decays into beauty, while beauty soon becomes merely
    charm. Charm ends up as strangeness, and even that doesn't last, but
    up and down are forever. - Anonymous

    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

+ Reply to Thread