Faster! Faster!

dslodkidslodki Registered User
To the powers that be...
I'd like to put in a request for a faster video card on the HogIII. The views are limited in functionality for me because I have to decide if it's worth the lag in time to wait for all the screens to change after selecting a new view or figure something else out (scroll down, close a window, etc.)
Thanks,
Dave

Comments

  • Marty PostmaMarty Postma Registered User
    edited March 2006
    I second the notion of speed!

    Does it require a faster vid. card, or does it have more to do with the now old Linux Kernel? Maybe both?

    I think there is work being done to speed some of this up in v1.4.0 for the console.

    Any enlightenment from the Gurus?
    :notworthy:
  • bradpepebradpepe Registered User, HES Alumni
    edited March 2006
    Marty and Dave,

    We are aware of the current problems related to views and we are continuing to make improvements to them with each release. This is a high priority issue and we hope to have them working much better as soon as possible.

    One thing that can help is to only use external monitors when really needed and if not using any external monitors, ensure that they are disabled in the control panel. Even if they are not plugged in, you will notice a slow down if they are enabled.

    thanks,
  • dslodkidslodki Registered User
    edited March 2006
    I'm assuming you mean "(in the meantime) use external monitors only when needed"
    Dave
  • bradpepebradpepe Registered User, HES Alumni
    edited March 2006
    Dave,

    Yes that would be a correct assumption.
  • barnes2000barnes2000 Registered User, Hog Beta
    edited March 2006
    Brad,

    Does the resolution setting of the externals make any difference in the speed?
  • teericksonteerickson Registered User, HES Alumni
    edited March 2006
    Scott,

    Absolutely, as does the refresh rate.

    Think of it this way:

    Running the 2 internal monitors at 800 x 600 @ 60Hz, we are drawing 960,000 pixels (800 x 600 x 2) 60 times each second, or 57,600,000 pixels per second.

    Enabling both external monitors at 1280 x 1024 @ 75 Hz, this adds 196,608,000 pixels each second (1280 x 1024 x 2 x 75).
    Some of this load is handled by the video card and not the CPU, so it won't directly affect the response of the console, but if you put windows that have lots of constantly changing data on these screens, like the Output window, Cuelist windows, or the DMX window, the processing for updating the data in these windows is handled by the processor on the motherboard and that can have a noticable effect on the responsiveness of the console.

    We are currently working hard to improve performance in ways that would directly benifit these specific situations, but for now the best advice is to minimize your external monitor resolution and refresh rate, be careful about which windows you have open, or disable one or both external monitors to increase the performance and responsiveness of the console.
  • captnstewbngcaptnstewbng Registered User
    edited April 2007
    Well Tom... You'll love this.

    I'd like a higher resolution available on the external monitors. Reason being, I'd like to be able to see, as an example, the whole output screen at once without having to scroll up/down or right/left. At the moment, I have to scroll right to see all of the parameters of my Studio Spots.

    As Tim 'The Tool Man' says... "More power!"

    Thanks.
    Kerry
  • teericksonteerickson Registered User, HES Alumni
    edited April 2007
    Kerry,

    I'm actually glad that you revived this thread. I'd be curious to hear what folks have to say now that we've released v2.1 with all of its views performance improvements.

    I certainly agree with you that it would be nice at times to be able to use higher resolutions on the external screens (although I'd then have to buy nicer touchscreens).

    The limitation here is actually hardware. If you've ever opened the back of your Wholehog 3, you'll see that our motherboard is completely custom and that we don't use any PCI / AGP / PCI Express cards. We use 2 video chips to control the 4 screens, but they are only 4MB each, with each chip running 1MB for an internal screen and 3MB for an external screen. This allows us 800x600 for the internal screen and a max of 1280x1024 for the external, both at 16 bit colour depth.

    Increasing the maximum resolution of the external screens would require a motherboard replacement.

    The good news is that the Hog iPC allows higher resolutions on the external screen and that on the Wholehog 3 console, with our recent views work, will properly recall window scroll positions and the Jump toolbar should be working well.

    I hope this answers your question.
  • captnstewbngcaptnstewbng Registered User
    edited April 2007
    Tom,

    I haven't updated to v2.1 yet. I haven't had the time to back up all of my shows and do the update. Nice to know that view performance was improved with the latest update. May have to find time to do all of the back-ups.

    I wouldn't mind bigger touch screens. I generally like to be able to see everything at once. If the motherboard gets updated at some point in the future, add functionality for 2 more external touch screens. My Hog is in a high school, you can't have enough monitors.

    If you built a motherboard with substantially better video chips and capability, I'd buy it.

    Was there a specific reason why the 16 bit color was chosen? Color picker perhaps?

    Not to change the subject of the thread, but is there a way to use the USB ports on the HogIII console to dump a show file onto a flash drive?

    Thanks,
    Kerry
  • teericksonteerickson Registered User, HES Alumni
    edited April 2007
    Kerry,

    I believe that the embedded video solution that we use (not unlike many that were available at the time the motherboard was designed) actually is limited to a maximum resolution of 1280x1024. With the amount of memory we have and what we need to drive, we had available memory to run at 16 bit colour depth.

    You're right that most of our application would probably look fine with fewer colours, but the colour picker would definitely take a hit and this gives us options for nicer icons and will be very helpful as we look forward to features like media server integration.

    We are currently working on adding support for USB mass storage devices. The problem is that our current linux kernel (2.4.19) has really bad support for them. We're working on a kernel upgrade, but that requires a compiler upgrade, and the new compiler is a bit more strict than what we'd been running in the past.

    Our developer working on the compiler port is nearly complete and we've documented the few kernel modifications that we have. I can't make any promises about dates, but most of the difficult parts of implementing USB drives are being completed right now as a part of a separate project. I'm hoping to see USB drive support in the not-so-distant future.
  • quinnquinn Registered User
    edited April 2007
    teerickson said:
    the new compiler is a bit more strict than what we'd been running in the past.
    hooray! that's huge, and i'm thrilled.

    out of nothing but sheer curiosity, can you speak to how and why the full III's and/or the OB's haven't moved to XPe? seems like targeting a single platform just isn't possible...?
  • captnstewbngcaptnstewbng Registered User
    edited April 2007
    So, Tom, what you're saying it that you pretty much need a whole new motherboard?

    Shame on you for not thinking of every user request for every console you'd ever develop before hand. I guess I'll just have to find myself a new favorit lighting console.

    Kerry

    P.S. I'll get you some feedback when I go to v2.1.
  • nibornibor Registered User, Hog Beta
    edited April 2007
    Ok I have said this for years now the Hog 3 Is the best console out there but the motherboard was designed to slow not Highends bad they inherited
    it so why not fix it now and and go forward and kick ass
    So there is room for a new board in there charge old owners 1000 $ for a new
    lighting fast one and put it in all new one and go back to the top of the console world and stop trying patch it upgrade it

    Robin>>>> chew on that
  • teericksonteerickson Registered User, HES Alumni
    edited April 2007
    Quinn,

    Moving all of our console software and our nodes to Windows XPe would be a huge product and wouldn't necessarily offer our users any immediate or obvious advantages. We may head in the direction of a single OS in the future because this may offer us some convenience, but there are better places for us to be putting our development effort right now.
  • teericksonteerickson Registered User, HES Alumni
    edited April 2007
    Kerry,

    Yes. To upgrade our video hardware in the Wholehog 3 console, we would need a new motherboard. Remember that the first Wholehog 3s were sold in 2001 and the hardware design was probably being worked on for a couple of years before that. Current technology for embedded solutions in the late 1990's was significantly different than what we have available today.

    Luckily, as I mentioned above, we don't see any evidence that the video chips are a performance bottleneck for us.
  • teericksonteerickson Registered User, HES Alumni
    edited April 2007
    Robin,

    We've had this same discussion in a number of threads here, so I'm going to start by responding to you with one of my previous responses to you.

    "Changing the hardware in the console isn't going to affect how frequently it crashes.

    Changing the hardware on the console would be a *huge* undertaking. If you want hardware that can be installed into existing consoles then we would have to design a custom motherboard, which is an expensive and time consuming project.

    All of the resources that would be dedicated to designing, developing, and testing this new hardware are resources that would no longer be available to work on other development projects, including improving the stability of the console."

    That fairly well sums things up. The Wholehog 3 uses a custom motherboard. We would not be able to find a motherboard that could retrofit into existing consoles. We would have to design one. Designing a custom motherboard is a far larger project than you seem to understand. In addition to being possibly the most complex hardware component in the product line, it also requires much more firmware to be developed. You also seem convinced that this new hardware would somehow reduce crashing. Crashing is caused by problems within an application. That is currently where our efforts our focused. A new motherboard wouldn't cause us to crash less, it would just allow us to crash faster.

    As we have *proven* with the development that has happened in the past 18 months, it is very possible for us to improve performance and stability with software changes to our application. This offers actual solutions to legitimate software bugs rather than throwing faster hardware at the problems and also gives us a solution that our users don't have to spend money to get.

    You mention that we should sell this new motherboard for $1000. I have no idea how you've arrived at this number, but as I've mentioned above, I don't think you understand the costs involved in a project like this. Your $1000 price is far less than our current motherboards cost. Remember that we don't have the benefits of the economies of scale that a major PC motherboard manufacturer would have.

    I'd like to close by quoting myself in another previous response to you.

    "We are constantly working to improve the performance of the console in ways that will have the greatest impact for the majority of our user base, as you can tell by the recent views improvements. If we make hardware changes to the console, we will need to sit down and find the best way to make those improvements available to existing users. This decision will be affected by a number of factors, including cost, mechanical compatibility, and customer needs. I think you're putting the cart in front of the horse here. Keep in mind that we're all happiest when our users are happy and that's what we strive for, but we do need to make feasible business decisions that allow us to continue working to improve the product."

    I belive I've "chewed on" everything you said. If my responses don't answer your questions, please feel free to ask for clarification.

    Thanks.
  • nibornibor Registered User, Hog Beta
    edited April 2007
    Love it, Ok how about 1200 bucks to the cost of the mother of boards
  • teericksonteerickson Registered User, HES Alumni
    edited April 2007
    Robin,

    It seems that you're not understanding me, but I don't know how I can explain myself any better.

    So, I'm going to paraphrase exactly what I've already said, yet again.

    a) New hardware isn't going to improve software stability.

    b) New hardware is going to take valuable development resources off of existing projects that will provide valuable benefits to the majority of our user base.

    c) New hardware is going to be more expensive than you think, because we wouldn't be able to use an off-the-shelf motherboard if we want to be able to retrofit existing consoles. I'm not sure how much our current replacement motherboards cost. It might interest you to check with your local dealer and find out what the current boards cost and use that for perspective.

    We all understand that you want a new motherboard. I've tried to explain why we feel that isn't the best use of our resources. As I mentioned before, our primary concern is getting the biggest functional, performance, and stability improvements as efficiently as possible for as much of our user base as possible. You'll have to believe me that we've put lots of time and effort into determining the best way to do this, because there isn't much else that can be said or re-said at this point.

    I hope you understand.
  • nibornibor Registered User, Hog Beta
    edited April 2007
    Ok tom my old mate , I am see a grate strangenes when I use a macro to change page This is a very cue intence show 90 gobo changes fade one load one ok it like the timeing go's away for a bit it freaks me out then it comes back there is 600 cues in this show and many page changes and every time I change page timing is gone then it catches up what do you think of that.
  • bradpepebradpepe Registered User, HES Alumni
    edited April 2007
    Robin,

    Please send me your show file via the uploader utility http://upload.highend.com and also send me an email with the detailed information (exact button presses) to reproduce the problem described above.

    Also please clarify in the email what you mean when you say "the timeing go's away for a bit". Do you mean the cuelist window, the playback, the screen refresh, etc?

    All problems are very important to us and we try to resolve everything in a timely manner. Often problems can only be reproduced with clear reports and show files. Once we reproduce a problem, then we can make headway into fixing it.

    thank you for your understanding and continued support of our products,
  • ebardesebardes Registered User
    edited April 2007
    teerickson said:
    Kerry,
    I'd be curious to hear what folks have to say now that we've released v2.1 with all of its views performance improvements.

    I'm into my second show on the 2.1 version with the PC version. I think my only "complaint" is that it appears my CPU usage increases significantly when I have the Output View active.
  • teericksonteerickson Registered User, HES Alumni
    edited April 2007
    Eric,

    This is to be expected. The output window is driven almost entirely by feedback and this feedback must be prepared and collated for display when the output window is open.

    We're currently working on changes that will reduce this impact.
  • captnstewbngcaptnstewbng Registered User
    edited January 2008
    Hi Tom,

    I have some feed back for you regarding the updated Hog software that included performance enhancements. To review, we were talking about monitor resolution, color depth, and how available memory limitiations were affected by the current available technology at the time of motherboard design. I was reminded of this thread when I went to update my Hog from v.2.0 to 2.2. When I originally attempted the update I was unable to move from v2.0 to 2.2 because the Hog would not accept the new software. Long story short I had to go back to the original software that shipped with the console (v1.4 I think). With help from tech support, I eventually got v2.2 running.

    Having delt with that, I was able to compare the performance speed more easily due to the short time between using both v1.4 and v2.2. Overall, it seems as though v2.2 runs at roughly the same speed as v1.4 with 2 noticable differences. First, and I noticed this on v2.0, there seems to be what I will call a 'floating flicker' on both internal and external monitors. Sorta kinda what CRT monitors look like in older movies where you could see the CRTs refreshing themselves. Not all monitors at the same time or not a whole monitor at once though. It seems to be a occuring at a random spot on a random monitor. It's annoying, but I have almost stopped noticing.

    The second thing I have noticed is that is takes what seems to be forever to get to the Record Option window if I am writing over a Group, Scene or Cue. That's been somewhat more difficult to work with.

    The other thing I'd like to add about v2.2 it that it seems to be good deal more stable. My Hog crashes less now. That's good times.

    I hope this is useful.

    Thanks,
    Kerry
  • teericksonteerickson Registered User, HES Alumni
    edited January 2008
    Kerry,

    Thanks for the update. I'm definitely glad to hear that you're feeling like the console is more stable.

    The v2.1 release had the most impact on console performance, as it included some *significant* changes to how we draw data on the screens. In most cases, and most specifically the output window, performance was significantly improved. There were a couple of areas, specifically the effects engine spreadsheet and the colour picker, that suffered a slight performance decrease, but we've improved these areas in releases since v2.1.

    I'd like to know how you're gauging the console performance. There are two areas where I'd expect you to see improvements:

    1) Refresh rates in the output window are consistently higher than they were previously. This is particularly noticable when running crossfades or effects.

    2) When lots of windows are open that require constant redrawing based on feedback (output, cuelist, etc.), and there is lots of data, the responsiveness of the front panel and command line should be improved. In addition to making drawing to the screen more efficient, we've also basically limited it to a percentage of total CPU time so that there is always processing power available to handle user input.

    Thanks.
  • nibornibor Registered User, Hog Beta
    edited January 2008
    Useing exturnal monitors still slows things down,
    Tom
  • bradpepebradpepe Registered User, HES Alumni
    edited January 2008
    All,

    As Tom said v2.1 marked a big change in views. We are continuing to improve the views, refresh, etc and elected to implement these changes in steps instead of waiting to add them all at once. Of the planned improvements in this area about 1/3 have been implemented. Our development team is continuing to rewrite much of this code and you will see over the course of the next few releases more and more improvements in this area.

    In addition these improvements not only increase speed they allow for implementation of future GUI features and enhancments. So the work not only improves the current system, but opens avenues for newer functionalites to be added with much greater ease.

    We understand the desire to have faster views and we are working to satisfy all the users needs as quickly as possible. Thank you all for your patience and understanding.
  • captnstewbngcaptnstewbng Registered User
    edited January 2008
    Tom,

    Thanks for getting back. As far as how I am gauging performance here's what I can tell you...

    I have 1 external 19" LCD monitor that runs natively at 1280x1024.

    When patching (I forgot about this during my last post), I'm generally only looking at the patch window. I think I see the worst lag when patching. I usually have to wait for the console to catch up after pressing the '@' key and then have to wait again after pressing 'enter'. It gets really bad when patching 3 digit DMX addresses into 3 digit channel numbers.

    When I'm programming, I am looking at the cuelist, output, programmer and group windows. That's certainly a heavy load as far as displays go but the funny thing is that if I add patching to this, there does not appear to be a disceranble increase (or decrease) in lag time.

    In all instances I cannot tell if the console is slow to display changes or slow to execute the commands. I'll have to play around a but to find out if its one or the other.

    Kerry
  • teericksonteerickson Registered User, HES Alumni
    edited January 2008
    Robin,

    Using external monitors will always have some degree of impact on performance because it's lots of additional pixels that need to be painted and usually means additional windows that we need to keep track of.

    Kerry,

    I don't believe that we made any changes specific to the patch window, but I'll let our test department know that you're feeling like this speed in this window is holding you and they can look into this report.

    Thanks.
  • Firewood1Firewood1 Registered User, Hog Beta
    edited July 2012
    Hi there,

    I just wanted to pick this thread up as the last post is probably my single biggest annoyance with my WH3 console to date. 4 years have passed since the above post and still when I hit Ch***@, there is about a 1 second delay in opening the patch window. On my iPC it is instant. Patching on the WH3 takes far too long, as I keep making errors because of entering in the information faster than the console can react.

    Could this be looked at again please?

    Cheers

    Colin
  • dslodkidslodki Registered User
    edited July 2012
    Colin, maybe try running HogPC on another Windows CPU (something inexpensive like a netbook works great) and log your WH3 onto it as a client. I and others also find this is a VERY stable configuration for the network. And I think it's faster....not sure, though. (This thread is old, yes, subsequent builds of the WH3 have been much snappier. What version are you on?)
  • Firewood1Firewood1 Registered User, Hog Beta
    edited July 2012
    Hi there,

    Thanks for your response.

    I will certainly try this next time I reunite with the console, as I have now left the venue. I already have a backup PC laptop networked to the WH3, so very easy for me to connect them the other way around.

    I am running v3.2.3. As I haven't been able to assess whether I have one of the DP8000s that cannot be upgraded to v3.2.4, I have yet to make that change.
  • MitchMitch Registered User, HES Staff
    edited July 2012
    Hi Colin, I see you mention DP8000s that cannot be updated to 3.2.4.
    All DP8000s can be updated to V.3.2.4.
  • Firewood1Firewood1 Registered User, Hog Beta
    edited July 2012
    Hi Mitch,

    Thanks for clearing that up. The reason I thought it might not be possible to upgrade is because of a document posted in the iPC download section. The document states a certain age of DP8000 could not be updated, but I now realise this is an old document and does not relate to the most current software release.

    Apologies if I stopped anyone from updating in the meantime.

    Colin
Sign In or Register to comment.