Auctions Lag Issues

This is a continuation from my reply posted here: https://board-en.darkorbit.com//threads/back-page-issue.13765/

As DarkLord closed the thread without giving an opportunity to reply, I'm going to add it here:

You totally misunderstood my explanation (hey, what do I expect -.-). The issue has NOTHING to do with the game nor its rendering. It has to do with the rendering of the WEBPAGE! Before you accuse people of not being able to help because we don't know what we are talking about (typical Bigpoint), please try and understand the explanation first. Lets go through this again.

My previous post explained it like this:

Lets go through and explain how I am correct in my statement and explanation.

If you first browse to the Auction page and browse the source, scrolling down a bit you will come to the table layout section that represents the auction items. A snippet looks like this: (Please note that I "beautified" the source to make it readable)

HTML:

<table width="448" cellspacing="0" cellpadding="0" class="fliess10px-white" border="0">

    <form name="auction_1" id="auction_1" action="indexInternal.es?action=internalAuction" method="post">
        <input type="hidden" name="reloadToken" value="xxx">
        <input type="hidden" id="subAction_1" name="subAction" value="bid">
        <input type="hidden" id="itemId_1" name="itemId" value="ammunition_laser_mcb-25">
        <tr>
            <td class="trade_img">
                <img src="http://darkorbit-22.level3.bpcdn.net/do_img/global/items/ammunition/laser/mcb-25_63x63.png?__cv=86c2c2d261ef196310b34fb3f92c6800" width="63" height="63" alt="">
            </td>
            <td class="trade_item" showUser="xxx">
                More bang for your buck: x2 laser damage per round (1,000 units)
                <br />Highest bidder:
                <span class="userInfoName" title="xxx - click for details"> xxx</span>
                <br />
            </td>
            <td class="trade_buy">
                <span class="trade_buy_price fliess11px-gelb"><strong>350 U.</strong></span>
                <a href="JavaScript:void(0)" class="trade_buy_button" onclick="getQuantityManager('ammunition_laser_mcb-25'); return false">
                    <img src="http://darkorbit-22.level3.bpcdn.net/do_img/en/handel/b_sofortkauf.gif?__cv=3c9a8138dbadda854098c54040760c00" width="102" height="18" alt="Buy now">
                </a>
            </td>
            <td class="trade_bid">
                <input id="bid_amount_1" type="text" name="bid" class="trade_bid_price fliess11px-gelb" autocomplete="off">
                <br>
                <div id="sbmt_1">
                    <script type="text/javascript">
                        var rid = 'xxx';
                    </script>
                    <a href="javascript:void(0)" onclick="sendBid(1, rid); return false;">
                        <img src="http://darkorbit-22.level3.bpcdn.net/do_img/en/handel/b_bieten.gif?__cv=ac1419c1d7ef687e6daa80da96645400" class="trade_bid_button_submit">
                    </a>
                </div>
                <img id="wait_1" class="trade_bid_button_wait" src="http://darkorbit-22.level3.bpcdn.net/do_img/global/trade/b_bieten_wait.gif?__cv=0755c137dcb3d0a7767084afe6af1200">
            </td>
        </tr>
    </form>

This is the root cause of the issue already. As per the HTML spec you are not allowed to nest a `<form>` tag inside a `<table>` tag. In fact you aren't aloud any other tag apart from a `<tr>` or a `<td>` directly inside the `<table>` tag. You can see this by uploading the Auction page to a HTML validator like w3.org's.

Now when Chrome and any other browser encounters this "broken" HTML it tries to fix things. For example, Chrome kills off the `<form>` by immediately closing the tag:

HTML:

<table width="448" cellspacing="0" cellpadding="0" class="fliess10px-white" border="0">

    <form name="auction_1" id="auction_1" action="indexInternal.es?action=internalAuction" method="post"></form>
    <input type="hidden" name="reloadToken" value="xxx">
    <input type="hidden" id="subAction_1" name="subAction" value="bid">
    <input type="hidden" id="itemId_1" name="itemId" value="ammunition_laser_mcb-25">
    <tbody>
        <tr>
            <td class="trade_img">
                <img src="http://darkorbit-22.level3.bpcdn.net/do_img/global/items/ammunition/laser/mcb-25_63x63.png?__cv=86c2c2d261ef196310b34fb3f92c6800" width="63" height="63" alt="">
            </td>
            <td class="trade_item" showuser="xxx">
                More bang for your buck: x2 laser damage per round (1,000 units)
                <br>Highest bidder:
                <span class="userInfoName" title=""> xxx</span>
                <br>
            </td>

Now due to this "fixing" done by the browser, whenever the DOM (Document Object Model) is changed, Chrome has to update the DOM, then fix it again causing the entire table to be modified and re-rendered. What changes the DOM you might ask? Well see that timer thingy up the top, it kinda looks like this: . Well every second that timer is updated causing the DOM to be modified, causing Chrome to fix the entire table again causing it all to be re-rendered. Now this would normally be fine because Chrome is generally good with re-renders (it has a nice validation pipeline and wouldn't normally re-render it all because most of the DOM hasn't changed) BUT the table being fixed causes a "DOM Modified" event to be raised. This is important!

Why is that important you might ask? Well good question. If you scroll right down to around line 3389 of the Auction page source code, you will see the javascript that handles the pretty scrollbars on the auction page. For those of you too lazy, it looks like this:

Code:

jQuery('.auctionContent').jScrollPane({autoReinitialise: true, showArrows: true});

Now there are two options being passed here, one called autoReinitialise
and one called showArrows. Now the key to all this is autoReinitialise. As you might guess, this option tells jScrollPane (the scrollbars remember) to re-initialise (to recreate the scrollbars) every time a DOM Modified event is raised. And now we see the whole picture! Because every second we modify the DOM to update the timer, Chrome and other browsers have to revalidate and then fix the invalid HTML code inside the table in the auctions page. This causes a DOM Modified to be raised every second which the jScrollPane is listening to. So now... every second... the jScrollPane is completely recreating the ScrollBars for the auction page, in the background, EVEN IF you aren't on the tab. This is what causes continual freezing in the game when you have your auction tab open.

Still don't believe me? Here is a profile of the auction page. The following screenshot shows the amount of time spent re-rendering and updating the auction page after the timer event is fired. This occurs every second.

What's worrying is that for an event that occurs every second, its taking almost 0.2 seconds to run. That means its using roughly 20% CPU usage (I say roughly because its not quite equivalent) to update the Auction page.

 

#Push

Still no comment? Come on Bigpoint, try have some transparency for once!

 

A very good post here pinpointing the exact problem. My guess is that since the auction is being "reworked" they aren't interested in spending any time to fix this. I just hope they don't make the same mistake in the reworked auction.

I don't know a massive amount about coding but this current problem shouldn't be too hard to fix, right?

 

I get lag on the game from most pages, especially any which also uses flash (like if I load Galaxy Gates page when in the pali field my Flash Player crashes. The best page I've found to "live" on when game is open in the Pilot Profile (no special effects there!) but ofc this is my workaround rather than any kind of fix or distraction from the real issue being fixed.

 

There are two easy fixes,

1. Set autoreinitialise to false
2. Fix the auction page HTML to make it valid!

 

Hello -»DостогUηζεαsнεd«-,

The issue with the auction page and possible lag effects from it was already stated in the previous thread that you posted in as being looked into. Since this issue has already been brought to our attention and to avoid any further multiple posting of a same issue, I am closing this thread. Please do not post multiple times on a issue that you know we are already investigating, it only slows the progress of getting those issues resolved. Thank you.

Closed ~ Already being investigated.

DarkLord