Page 1 of 1

Nistune slows down when Romulator is connected

Posted: Tue Jan 31, 2006 3:39 am
by Stinky
I noticed that when I connect to the Romulator while the USB consult is activated the live data display slows down quite a bit. As soon as I disconnect from the Romulator things come back to normal.

Posted: Tue Jan 31, 2006 4:15 am
by Matt
this is a threading issue. more threads slow the system down. i can have a look into it but in future once NVRAM is used, wont need the romulator anyway

i think the romulator thread is probably chewing up more time than it should. i'll post here when i get to look into it

Posted: Tue Jan 31, 2006 4:45 pm
by Matt
issue fixed. added sleep when romulator isn't doing anything. lots better now

currently putting logging into a thread since when recording it slows down cursor movement. similar issue

Posted: Thu Feb 02, 2006 2:03 pm
by Stinky
I tried making some changes with the Romulator last night with version .701a. The speed with the romulator connected is improved. Couple of little things though.

- When applying changes such as K, feedback, or other values that have the apply button, Nistune will say "writing to..." and not say anything about being completed.

- When selecting multiple cells in either tables or the maps I cant seem to edit all the selected values at one time. For example if I selected the entire fuel map and hit + or pgup it wouldnt do anything. That or its really really slow. Actually this is the same when I use Nistune without the romulator connected.

Thats it for now I think.

Posted: Thu Feb 02, 2006 6:22 pm
by Matt
thats cos select and +/- isn't a feature. there is a fill option, which is select area and CTRL-F

i might be able to add a +/- with select perhaps. shouldn't be too hard....

you can also cut and paste. for some reason its a bit slow when doing those options, appears to hang but yes it works. something to fix still

okay i can add a response to the statusbar for those changes.

Posted: Fri Feb 03, 2006 12:31 am
by Matt
currently working on the mutliple cell update slowness

there is a queue of romulator update events designed to make things fast. unfortuatenly things get hung, and no updates end up happening

Posted: Fri Feb 03, 2006 1:19 am
by Stinky
I did notice that Liveedit has a similar issue as far as large updates happening slowly. It usually takes about 5 seconds or so to see any changes after doing a +/- on an entire map in liveedit.

Posted: Fri Feb 03, 2006 1:25 am
by Matt
okay during paste, clear, fill - if selecting say all 256 cells, each update is refreshing the graphic view

so 256 updates of the graphic view slows everything down badly. im adding in a separate cell update for multiple things, and then do a manual refresh afterwards

Posted: Fri Feb 03, 2006 2:25 am
by Matt
okay the cut/paste/fill/+/- are all implemented. they will only work in raw/filtered modes. there are no hangs and all works very nicely now :D

however it means you cant use these in hex, dutycycle, afr or pulsewidth. not a problem for timing but fuel maps might be hassle for now

its the problems you get where say raw values

147 may equal 15.6
148 may also equal 15.6

if you enter 15.6 on the keyboard, do i give it 147 or 148? i dont want to guess these things.

Posted: Fri Feb 03, 2006 2:40 am
by Matt
okay +/- will now work on selected areas in pulsewidth/duty/hex/afr modes now

i found a way to hack the gridcontrol class to call my increment/decrement functions multiple times and then do the graphics refresh at the end

currently grid entry will not allow direct editing (only +/-) or cut/paste/fill/clear in these modes

Posted: Fri Feb 03, 2006 4:23 am
by Stinky
Matt wrote:
147 may equal 15.6
148 may also equal 15.6

if you enter 15.6 on the keyboard, do i give it 147 or 148? i dont want to guess these things.
What about throwing in another digit. (15.62 instead of 15.6). Maybe use the fill function to get it in the general area and then if need be use the +/- to do fine adjustemnts.

Posted: Fri Feb 03, 2006 10:18 am
by Matt
i can try but the font may not fit in the cells. even then, if the user enters
15.56 and only 15.58 or 15.54 is available when converting to raw format, which one will i choose? it would have to either go hi or go low each time to the closest equal value

i should be able to do fill no problems, cut/paste and editing using keyboard entry are the difficult ones

Posted: Fri Feb 03, 2006 11:51 am
by Stinky
I think you'd be fine going low each time. Richer is safer so they cant complain about it killing anything.

Posted: Fri Feb 03, 2006 8:37 pm
by Matt
the fonts fit but im going to leave that one for now as an 'enhancement' unless you really need it. its only affecting direct entry and cut/paste

btw you can now use the mouse and ctrl to select various cells and only increment those if you wish rather than a block

live edit wont even let you edit these in normal mode

Posted: Sat Feb 04, 2006 1:27 am
by Stinky
I can live without the precision. The ctrl click feature will be very nice. Looking forward to trying that.