**** BEGIN LOGGING AT Mon Jan 23 02:59:57 2012 Jan 23 03:00:13 Brybry: why do u even have login prompt Jan 23 03:00:28 I have no idea Jan 23 03:00:32 I didn't write that =p Jan 23 03:00:42 u shouldnt Jan 23 03:00:46 (I don't have it, fwiw) Jan 23 03:00:47 I have a Password: Jan 23 03:00:47 unless Jan 23 03:00:53 which I have no clue and just hit enter Jan 23 03:01:19 then it gives me a Login: so I do root and I'm good Jan 23 03:01:29 umight get that if the wterm user didnt get made properly Jan 23 03:03:43 dtzWill: run nano and tell me if it looks weird Jan 23 03:03:55 with TERM=xterm Jan 23 03:04:08 or vt100 Jan 23 03:04:41 lol nano Jan 23 03:05:49 5$#%@#%# non-root Jan 23 03:05:49 lol Jan 23 03:05:59 and 'su' isn't suid, apparently Jan 23 03:05:59 as root :D Jan 23 03:06:23 dtzWill: read the readme :) Jan 23 03:06:36 PuffTheMagic: psh, readme :P Jan 23 03:06:48 Brybry: looks fine here? Jan 23 03:06:51 u need to add wterm to root group Jan 23 03:06:59 to su Jan 23 03:07:13 this is in stock shell, and no customization for nano, etc Jan 23 03:07:21 i just did 'nano' and typed a bit, then went to exit. Jan 23 03:08:22 and it looked fine? hmm Jan 23 03:08:24 ok, maybe it's just me Jan 23 03:08:31 with TERM=xterm, fwiw Jan 23 03:08:43 Brybry: by 'weird' do you mean incorrect characters or general rendering glitches? Jan 23 03:08:56 b/c atm something is tickling some rendering but that i haven't tracked down and that especially happens without the vkb active Jan 23 03:10:01 with xterm I'm missing the top inverse background bar thing Jan 23 03:10:07 I'll just take a screenshot Jan 23 03:10:41 looks fine to me Jan 23 03:11:05 like I said, might just be me Jan 23 03:11:09 maybe my install borked Jan 23 03:11:31 though my binary is definitely latest code Jan 23 03:11:35 well i'm not used to looking at nano, maybe i missed something. Jan 23 03:11:52 i have top bar Jan 23 03:11:58 i blame windowz Jan 23 03:12:33 http://img29.imageshack.us/img29/1769/wterm20122201210848.png Jan 23 03:13:21 vt100: http://img813.imageshack.us/img813/3733/wterm20122201210912.png Jan 23 03:13:33 SHIT Jan 23 03:13:37 SHIT Jan 23 03:13:41 SHIT Jan 23 03:13:44 lol Jan 23 03:14:08 wterm home cant be on / Jan 23 03:14:20 esp if it ges ro Jan 23 03:14:38 it should be somewhere in /var Jan 23 03:14:44 which is where root home is Jan 23 03:15:06 gonna have to fix postinst Jan 23 03:16:57 wterm standalone is even odder Jan 23 03:17:04 not that I actually need it to work like that Jan 23 03:17:23 odd how Jan 23 03:17:39 http://img259.imageshack.us/img259/6836/wterm20122201211515.png Jan 23 03:17:43 that's if I just spam enter a lot Jan 23 03:18:08 standalone is lowest of priority though Jan 23 03:18:40 i wish i could cut n paste from irssi/wterm Jan 23 03:21:58 i have to say, latest wterm is runni g pretty fuckimg great for e right now Jan 23 03:23:31 cut and paste should be doable Jan 23 03:23:34 maybe Jan 23 03:23:36 probably Jan 23 03:25:30 pull request sent for the bt input fix Jan 23 03:25:51 merged Jan 23 03:26:03 i've looked into ncurses mouse support Jan 23 03:26:12 its complicated Jan 23 03:27:49 we don't really need ncurses to do simple copy paste though, right? Jan 23 03:28:12 I dunno, I haven't read enough into the graphics state stuff yet Jan 23 03:29:45 i want to do full ncurses mouse Jan 23 03:30:21 so i dont want to half ass c-n-p Jan 23 03:42:17 PuffTheMagic: pmPostInstall worked when I mount -o rw,remount / Jan 23 03:42:24 not when it was ro Jan 23 03:42:35 how are you installing it? Jan 23 03:42:39 palm-install Jan 23 03:42:54 i was pretty sure it did that automatically Jan 23 03:43:29 the script has to do that if it needs it Jan 23 03:43:48 ok good to know Jan 23 03:43:53 Brybry, i will add that and move home to /var Jan 23 03:44:02 not a big deal, just good to know :) Jan 23 03:45:21 at least, I think that was it Jan 23 03:45:28 pushed Jan 23 03:46:27 oh, nice. the remove actually cleans up stuff so it's testable :D Jan 23 03:48:00 Brybry: yes there's a rendering bug that needs to be fixed, for sure Jan 23 03:48:21 Brybry: any information on that would be great, and what you're showing about on that link is something i've seen too and can more or less reliably reproduce Jan 23 03:48:37 it seems to happen after the reworking of the graphics state stuff, but honestly no change there seems like it could be blame? :/ Jan 23 03:48:38 Brybry, !!!!!!!!!!! Jan 23 03:48:44 i know why bash history wasnt saving :D Jan 23 03:49:03 but i can't look at it atm, unfortunately x.x Jan 23 03:49:22 top looks pretty terrible too hmm Jan 23 03:49:38 though, hmm Jan 23 03:49:56 that's gotta be purely a sdlfontgl issue :/, or 'mostly' anyway Jan 23 03:52:38 wtf Jan 23 03:52:43 prerm does not seem to be running Jan 23 03:53:34 or deluser isnt working from prerm Jan 23 03:54:11 I have this vague feeling that I tried it once and deluser didn't work at all Jan 23 03:54:29 it works when i run it as root manually Jan 23 03:54:43 ok Jan 23 03:55:49 ahhhh Jan 23 03:55:53 cause deluser is from opt Jan 23 03:56:03 not part of busybox Jan 23 03:56:30 what does deluser do besides remove the /etc/passwd entry? Jan 23 03:59:44 yea, I don't have a deluser Jan 23 03:59:54 should probably remount ro when we're done in pmPreRemove and pmPostInstall (or at least check to see if that automatically happens) Jan 23 04:00:12 nothing to do with rw/ro happens automatically Jan 23 04:00:29 that must be why I thought it didn't work :p Jan 23 04:00:47 Brybry, exit should reset the terminal or soemthing before it spawns new Jan 23 04:01:06 and/or inject some text to indicate that is has respawned Jan 23 04:02:12 oh god Jan 23 04:02:21 some of stbuehler parser shit is def broke Jan 23 04:02:32 but some is better than it was so.... guess its a wash Jan 23 04:05:45 htop is def broke Jan 23 04:07:25 it's ok though, cmatrix looks great Jan 23 04:08:03 :D Jan 23 04:09:40 sure does Jan 23 04:14:50 cmatrix will be exhibition mode soon Jan 23 04:21:32 Brybry: i get your nano bug now Jan 23 04:25:46 how do I get su to work (I get su: must be suid to work properly) Jan 23 04:26:39 look at the readme Jan 23 04:28:16 I swear I looked Jan 23 04:28:37 I guess I didn't :) Jan 23 04:28:52 I used cat and saw screenshot links :D Jan 23 04:37:13 Brybry: u get it? Jan 23 04:38:59 mmm? yeah Jan 23 05:29:33 PuffTheMagic: sent you a 'be nice to the user on exit' pull Jan 23 05:30:14 * Brybry goes to sleep Jan 23 08:37:32 PuffTheMagic: if you have good examples for things that don't work.. i'll try to fix them Jan 23 08:37:51 in the end normal shell, mc and cmatrix worked, so i was happy :) Jan 23 08:39:02 vttest doesn't pass all tests in konsole or xterm too, so couldn't compare it :) Jan 23 09:27:39 PuffTheMagic: aah. the vtterminalstate code often doesn't check for numValues, even if the values were optional Jan 23 09:27:48 instead it assumes unused ones are filled with -1 Jan 23 15:11:28 stbuehler, you have to look at the docs to see what the the defaults are when numvals are left out Jan 23 15:11:48 but menu 1 of vttest did work Jan 23 15:12:21 and how it looks in konsole is correct (assuming you have your rows/cols set right in vttest) Jan 23 15:12:31 htop is pretty broken Jan 23 15:12:35 that is a good test Jan 23 15:12:46 also check nano and vim Jan 23 15:16:20 yes, already working on i Jan 23 15:16:42 i have some graphic bugs in portrait mode Jan 23 15:16:51 not sure what triggers it Jan 23 15:17:03 ya i get some tearing now Jan 23 15:18:28 ready for large pull request? Jan 23 15:18:38 ya Jan 23 15:18:51 k Jan 23 15:20:13 i tried enabling 8-bit C1 codes, no idea whether they work Jan 23 15:20:40 cool Jan 23 15:20:55 alright its merged Jan 23 15:21:00 i will give this a shot in a few Jan 23 15:21:03 just woke up Jan 23 15:21:07 i think the bottom line is the problem in portrait mode Jan 23 15:22:52 PuffTheMagic: the problem with the values is that some sequences required no values, but accepted two, and would always access these two values without checking numvalues Jan 23 15:23:41 now i reset all values (it would probably be enough to reset all up to maxParams) Jan 23 15:39:15 ya Jan 23 15:44:40 stbuehler, runs much much better Jan 23 15:45:05 i added a exhibition mode last night that runs cmatrix Jan 23 15:45:18 cant get it to use the whole display though Jan 23 15:45:53 stops where the vkb would be even though there isnt one Jan 23 16:04:12 ok i am going to be away for the next 4-6 hours Jan 23 16:04:18 need to pack up and drive back home Jan 23 16:04:33 later Jan 23 17:00:48 stbuehler: thanks for the graphics refactoring ^.^ Jan 23 18:06:10 dtzWill: now you implement the unicode support :) Jan 23 18:06:44 what, getting the chars to the rendering is the easy part! ;) Jan 23 18:06:50 :P Jan 23 18:06:51 well Jan 23 18:07:01 the do it :) Jan 23 18:08:06 just think about memory limits perhaps :P 65536 chars * 4 styles... Jan 23 18:08:41 lol Jan 23 18:08:46 right, we talked about some resaonable subset Jan 23 18:08:49 perhaps the codepage -> unicode mapping should be implemented somewhere else now Jan 23 18:16:17 y'all are seeing rendering glitches fullscreen, yes? Jan 23 18:19:52 yes Jan 23 18:20:01 not in landscape mode Jan 23 18:20:06 good, b/c I think i've fixed that :D Jan 23 18:20:15 stbuehler: not in landscape, even with vkb off? Jan 23 18:22:51 hm Jan 23 18:23:19 ah yes, i see them now Jan 23 18:23:34 also fullscreen doesn't reach bottom Jan 23 18:23:41 yep Jan 23 18:23:42 same thing Jan 23 18:24:24 size miscalculations? Jan 23 18:24:39 you'd think so, right? Jan 23 18:24:41 haha Jan 23 18:24:59 that's what i was chasing, just b/c lots of that code is... err... 'error-prone' xD Jan 23 18:25:05 hehe Jan 23 18:25:11 so something really stupid i guess :D Jan 23 18:26:06 stbuehler: https://github.com/dtzWill/wTerm/commit/6fbd2f0df140bfcaede13f35b33f1487306f8766 Jan 23 18:26:28 btw: you know that you can kill remote branches with git push origin :kill-this-branch ? Jan 23 18:26:52 yeppers, i'd have many more if i didn't. but got lazy about it b/c if you do so github seems to lose track of it Jan 23 18:27:04 i mean in that when showing history/stats/graphs/etc Jan 23 18:27:23 and since github hides merged branches, maybe thought it was "github style" to kepe those alive, despite my own preference. Jan 23 18:27:36 but idk, maybe that's wrong. saying it out loud it doesn't seem as sound as i might've thought :) Jan 23 18:27:42 so, cols <-> rows and the arrays are too large for one call? Jan 23 18:28:24 well cols/rows doesn't matter at lal Jan 23 18:28:35 since i never use either individually Jan 23 18:28:40 i see Jan 23 18:28:49 just multiply them together to determine how much space i need to buffer operations Jan 23 18:28:57 but since i noticed it, figured i'd fix it Jan 23 18:29:01 but yeah just splitting the calls Jan 23 18:29:03 and all seems well here Jan 23 18:29:57 does someone need the unused functions in DataBuffer? Jan 23 18:30:02 i'd like to kill them Jan 23 18:31:15 and i don't think it needs a mutex, only accessed from the read thread afaics Jan 23 18:32:39 yeah, this code in general is...overlocked Jan 23 18:32:52 and i think we only use databuffer for the read/write buffering atm anyway Jan 23 18:32:55 which is....overkill, heh Jan 23 18:33:03 there should be no need for threads anyway Jan 23 18:33:44 stupid sdl, no fd hooks Jan 23 18:44:08 is there shader support on webos? Jan 23 18:47:27 for (ssize_t i=0; i < m_size; i++) { fprintf(out, "%c", m_buffer[i]); } Jan 23 18:47:29 oh the pain Jan 23 18:48:15 stbuehler: absolutely shader support, you mean like vertex/fragment shaders? Jan 23 18:48:24 yes Jan 23 18:48:29 we'll have to jump ship to GLES 2.0, but yep Jan 23 18:48:44 and iirc tp's GLES 1.0 is implemented with GLES 2.0 anyway :) Jan 23 18:48:45 so we could do the char texture offset calculations in shaders Jan 23 18:48:52 stbuehler: absolutely Jan 23 18:49:13 so we only need to upload char data and colors to the gpu Jan 23 18:49:20 stbuehler: we would probably also want to upload the color mapping as part of the cache, and just upload a single integer indicating which Jan 23 18:49:22 and not so many float values Jan 23 18:49:44 yep, just so far didnt' seem like those computations/uploading were enough of a bottleneck to justify the effort Jan 23 18:49:51 hehe Jan 23 18:50:21 (since tying those into our static image overlay, seems to complicate things) Jan 23 18:50:37 errr "static image overlay" i mean the thing we throw up for shift/contorl/etc, as well sa the cursor Jan 23 18:51:23 and now that the rendering code i contributed isn't doing things wrong, my work is temporarily done xD Jan 23 18:54:00 also funny is the use of sizeof(char) Jan 23 18:58:03 now that i think of it. we don't need DataBuffer at all Jan 23 18:58:08 well fwiw re:fast power of two, that power-of-two is only done 1x per resolution change :) Jan 23 18:58:10 and no i don't think we do Jan 23 18:59:50 hehe, that power-of-two should be implemented with templates in some header Jan 23 19:00:04 in some other place there was a map of them, that was really stupid :D Jan 23 19:00:17 uff Jan 23 19:00:25 signal handling.. well Jan 23 19:00:51 ooo someone's been touching up our tests or something, maybe this is because i'm using an updated vttest or something Jan 23 19:01:09 but they're working much better than when i left things when combining grpahics state with the cell text data Jan 23 19:01:12 \o/ whoever did that Jan 23 19:01:19 dumdidum Jan 23 19:01:29 only thing i see that's broken from before is the insert/delete test involving A******* ... ***B Jan 23 19:01:35 i like coding parsers Jan 23 19:01:52 oh was that the parser work? I didn't realize it was due to use misparsing Jan 23 19:01:56 hooray :D Jan 23 19:10:20 lol i love that PuffTheMagic_ merges things without being here on IRC :D Jan 23 19:10:33 (t!) Jan 23 19:10:34 *ty Jan 23 19:11:29 hehe Jan 23 19:26:53 what is the max rows x cols values? Jan 23 19:28:11 hmm? Jan 23 19:28:25 with vkb vttest says 28x146 Jan 23 19:28:38 so i assume we can have about 60x146 chars on the display Jan 23 19:28:41 *2 for background Jan 23 19:29:12 numchars >= 17k Jan 23 19:29:20 full-screen portrait has numChars == 12672 Jan 23 19:29:26 (no vkb) Jan 23 19:29:56 96/66 Jan 23 19:30:03 oh that's at w/e font size i have, of course Jan 23 19:30:03 XD Jan 23 19:30:19 and i've inflated it while doing this stuff so i can see from across the desk more easily Jan 23 19:30:22 so maybe nevermind those stats :) Jan 23 19:30:35 kk :) Jan 23 19:52:02 the A****B is an insert test Jan 23 20:08:16 yay, A****B works Jan 23 20:15:07 cmatrix leads to 80% cpu usage of wterm Jan 23 20:15:13 that could be better :) Jan 23 20:22:51 stbuehler: \o/ re:fixing a***B test Jan 23 20:23:10 and yeah it's not the best re:cpu usage. have you profiled it to see what's the bottleneck? Jan 23 20:25:19 oh wow cmatrix on my desktop uses 0% cpu Jan 23 20:25:30 okay yeah we can do better than 80% xD Jan 23 20:25:51 errr maybe 2%, shrug Jan 23 20:50:27 is there a reason not to use some sdl based timers? Jan 23 20:53:01 stbuehler: for which? Jan 23 20:54:13 blink Jan 23 20:54:34 (i don't like threads) Jan 23 20:57:23 hmm, that'd be nice. might as well move the keyrepeat stuff there too, no? Jan 23 20:57:31 there==using SDL_AddTimer or whatever Jan 23 20:58:38 would clean up the event loop a bit too i think Jan 23 21:01:06 The timer callback function may run in a different thread than your main program, and so shouldn't call any functions from within itself. You may always call SDL_PushEvent, however. Jan 23 21:01:10 ... Jan 23 21:01:25 lol yep Jan 23 21:01:38 but we could use it to trigger both blink and key repeat events Jan 23 21:01:48 blink could be a custom event, and key repeat could just be the relevant key event Jan 23 21:02:04 ..maybe? sorry i'll let you design this since it sounds like you might be the one tackling it :3 Jan 23 21:02:48 hm Jan 23 21:02:56 but it pushing the timer to SDL might fix some jitter/drift issues we have with our hand-rolled timers Jan 23 21:03:10 well, i have some experience with async stuff :) (coding webserver helps...) Jan 23 21:03:27 it seems like there is no sleep in the sdl loop Jan 23 21:03:42 so while keyboard repeat is active -> busy wait Jan 23 21:04:00 ah no, a dely Jan 23 21:04:02 hm Jan 23 21:04:04 in _our_ 'sdl loop' (event loop) or do you mean in something internal to sdl? Jan 23 21:04:54 and yeah, the idea being "consume the event queue eagerly before bothering to render" which is what's recommended across the board (I guess some bound on the queue size guarantees some measure of responsiveness??) Jan 23 21:05:58 and the sleep maybe should be ripped out, i don't know. the idea was to throttle rendering, so that time that could be spent processing input (from the terminal, not keyboard) wasnt spent rendering at a rate faster than made sense Jan 23 21:06:11 anyway please do revamp that if you think that could be done better, please and ty :3 Jan 23 21:06:25 (just trying to explain the motivations behind the things i've touched) Jan 23 21:07:53 kk, ty Jan 23 21:09:27 (I know you said you have experience, but at lesat now you have a partial "what was this guy thinking" with regards to those portions) Jan 23 21:09:29 * dtzWill goes back to reading Jan 23 21:22:57 while keyboard repeat is active/someone is holding down a key we're just limited by the standard fps limitation (the sdl delay, and this part could definitely be improved) otherwise it blocks/sdl_WaitEvents Jan 23 21:23:46 and from my understanding SDL_WaitEvent gives the best idling behavior out of the SDL options (even better than SDL_Delay) Jan 23 21:24:30 the key repeat stuff might be better in its own thread but I wasn't sure if it was worth the overhead Jan 23 21:25:24 I think we also have a 'blink' thread that fires off a SDL_VIDEOEXPOSE every .5 seconds or something Jan 23 21:33:22 I think the only other VIDEOEXPOSE source is supposed to be when terminal.cpp calls sdlterminal.cpp::insertdata Jan 23 21:35:04 well, if SDL_AddTimer wouldn't be run in another thread it would be easy... Jan 23 21:40:37 we definitely could benefit from some sort of dirty drawing system in some cases Jan 23 21:46:56 I don't think the keyrepeat stuff (that's like one if comparison call every event loop) or even the blink thread affect cmatrix performance Jan 23 21:48:18 more like pushing 16k*48 floats Jan 23 21:48:37 I imagine the thing with cmatrix is every little change it sends causes a full screen redraw Jan 23 21:48:56 2.5MB per refresh Jan 23 21:49:13 i checked strace and it read like 2500 chars per read (buffer for 4kb) Jan 23 21:49:52 hmmm Jan 23 21:49:57 key repeat definitely uses more cpu than it used to =/ Jan 23 21:50:23 or drawing or something Jan 23 21:50:35 well, i first want to break the stupid inheritance things (sdlfontgl -> sdlcore -> sdlterminal) Jan 23 22:29:26 ouch, so much ugly code Jan 23 22:29:39 pthread_mutex_lock(&m_rwLock);return m_currentGraphicsState.g0charset;pthread_mutex_unlock(&m_rwLock); Jan 23 22:29:42 srsly Jan 23 23:02:37 lol! Jan 23 23:03:03 err Jan 23 23:03:15 ugly or probably nonworking? Jan 23 23:03:30 nonworking, and probably unused Jan 23 23:03:49 nonworking, presumalby unused since we don't have the terminal locking up Jan 23 23:04:06 i will cleanup that charset/slot stuff Jan 23 23:04:10 totally useless Jan 23 23:04:19 haha xD great Jan 23 23:04:53 but not tonight, i have a bad cold and should get some sleep, not like yesterday :) Jan 23 23:14:13 well, gn8 :) and don't touch anything, i hate doing merges :P Jan 23 23:14:42 lol Jan 23 23:14:54 i love github Jan 23 23:15:04 doing merges while driving 80mph down the highway :D Jan 23 23:17:49 PuffTheMagic: :D Jan 23 23:20:33 awesome Jan 23 23:20:39 TP battery is dead again Jan 23 23:33:47 dtzWill, waiting to try these changes is killing me Jan 23 23:33:51 you guys we re busy today Jan 23 23:34:09 dtzWill, stbuehler Brybry I really appreciate all your effort and that you have joined the project Jan 23 23:35:15 our redraw()s are way too costly :( Jan 23 23:35:41 of course that is gonna be costly ;) Jan 23 23:41:20 I mean like 2% cpu usage if I comment out redraw and hold down a repeating key to 80-90% cpu with it enabled and do the same Jan 23 23:41:22 it shouldn't be THAT costly Jan 24 00:00:20 TP booted Jan 24 00:00:27 pretty nice to see cmatrix auto run :D Jan 24 00:06:27 ahh fullscreen cmatrix Jan 24 00:06:35 now if only it actually went into fullscreen mode Jan 24 00:12:01 ok if cmatrix is gonna be our exhibition mode app we need to "fix" is so that is doesnt run when exhibition mode isnt running Jan 24 00:12:23 cause according to htop there is a rogue cmatrix processing running :D Jan 24 01:06:39 switching to http://www.khronos.org/registry/gles/extensions/OES/OES_draw_texture.txt might help, idk Jan 24 01:07:01 "this capability is useful for faster rendering of .... bitmapped font glyphs..." Jan 24 01:07:07 *fast rendering Jan 24 01:09:30 and grep'ing libGL shows that we at least have the symbols for that extension, haven't tested if the hardware actually supports it Jan 24 01:16:48 dtzWill, would we still need the static glyph cache for that Jan 24 01:18:15 yes? Jan 24 01:18:32 I've been trying to make it so that redraw() only redraws terminalstate characters that have changed (which is easy) but I dunno how to handle the actual rendering part Jan 24 01:19:09 * Brybry doesn't know opengl Jan 24 01:19:26 well in the new world order, should just need to call drawTextGL on those characters (see existing redraw()) Jan 24 01:19:45 however various things assume blanked screen previously, but ripping out glclear()'s and such might get it done Jan 24 01:20:00 if I stop the opengl from clearing the buffer/glclear() things go very very wrong Jan 24 01:20:21 oh? Jan 24 01:20:36 yuo'll have to make sure you're also calling drawTextGL on the removed characters too Jan 24 01:20:41 something we don't necessarily do atm Jan 24 01:22:40 with our new erasing we actually create new TSCell_t to erase stuff Jan 24 01:22:54 we should in most cases, yes Jan 24 01:22:55 so it's pretty easy just to flag those as 'dirty'/changed Jan 24 01:22:58 kk Jan 24 01:23:23 honestly i'd prefer if we just always had all cells always to avoid some of the complexities. maybe the rendering is actually slower, idk. Jan 24 01:23:49 we do now Jan 24 01:23:58 or do you mean draw all of the cells always Jan 24 01:24:33 well there are numerous cases where a line isn't the full width of the screen Jan 24 01:24:36 from what I can tell every line is now max length Jan 24 01:24:40 it might "usually" be due to our erasing policy Jan 24 01:24:40 I think Jan 24 01:24:50 my testing could have been wrong Jan 24 01:24:55 but look for all the "TSLinet()" calls and those are empty lines Jan 24 01:25:02 that's actually probably why I saw increased cpu usage Jan 24 01:25:16 maybe we're drawing blank characters that we weren't drawing before, hmm Jan 24 01:25:16 nah it's not wrong so much as incomplete. we probably quickly move to the full-line case, but it's not an actual invariant Jan 24 01:25:17 * Brybry checks Jan 24 01:25:29 oh we for sure are :) Jan 24 01:25:49 lol maybe someone should add into drawTextGL "if (c == ' ') return" Jan 24 01:25:54 (after drawing the background) Jan 24 01:25:55 LOL Jan 24 01:26:21 I also removed like 234234234 setDirty(BUFFER_DIRTY_BIT); Jan 24 01:26:35 not that I plan on commiting any of this Jan 24 01:26:52 I'm pretty much destroying it just to figure out which calls are costly Jan 24 01:27:20 isnt there a profiler that can do that for you? Jan 24 01:27:23 but is there a reason redraw() would need to indirectly setDirty(BUFFER_DIRTY_BIT);? Jan 24 01:27:47 well Jan 24 01:27:49 the meaning Jan 24 01:27:53 of BUFFER_DIRTY_BIT has changd Jan 24 01:27:54 guys, drobbins (of gentoo/funnto fame) is not a wterm user :D Jan 24 01:27:56 i think, by me. Jan 24 01:28:03 it used to mean "we need to call swapbuffers" Jan 24 01:28:09 but now it means "we need to redraw" Jan 24 01:28:49 (and in moving to latter definition, don't redraw more than 1x per 'tick', unlike we used to block on redraw between every charcter inputted >_>) Jan 24 01:29:11 anyway Jan 24 01:29:11 err Jan 24 01:29:11 wait Jan 24 01:29:16 redraw sets the dirty bit?! Jan 24 01:29:17 roflrofl Jan 24 01:29:20 oohhhkaay Jan 24 01:29:21 well Jan 24 01:29:21 uh Jan 24 01:29:23 i'm sorry guys Jan 24 01:29:25 rofl Jan 24 01:29:32 it wasn't actuallly a huge performance loss/gain there Jan 24 01:29:34 i broke the gibson Jan 24 01:29:37 it was just causing a few extra redraws Jan 24 01:29:39 from what I saw Jan 24 01:29:48 no, it means we HAVE to redraw every tick Jan 24 01:30:00 which i guess might probably be the case anyway (what events trigger that we don't redraw for?) Jan 24 01:30:04 but is stil lulz fail Jan 24 01:30:13 since the code that clears that bit calls redraw() Jan 24 01:30:20 this is what code review is for >:O /me pretends he's not responsible Jan 24 01:30:38 nah, if those set diry are removed then it only redraws on a VIDEOEXPOSE Jan 24 01:30:47 I think Jan 24 01:31:01 dtzWill, when is wterm gonna support x11 forwarding? Jan 24 01:31:04 right but videoexpose is called from sdlterminal.cp::refresh Jan 24 01:31:15 or w/e it is that's called whenever any state is changed on the terminal Jan 24 01:31:43 yeah but refresh() is only called on sdlterminal::insertData() which is only called by terminal.cpp or something Jan 24 01:31:52 or something like that Jan 24 01:32:09 right, which is called every time we get text from the underlying shell process Jan 24 01:32:13 right Jan 24 01:32:36 all i'm saying is ripping out extra ones is probably good :) Jan 24 01:32:58 ok anyway, how to draw on the screen without erasing old buffer hmm Jan 24 01:40:31 if I want to save the whole current state of the screen/buffer what would be the best way to do that? Jan 24 01:41:25 this would help me as well ^^ Jan 24 01:41:56 i need it for the xterm special features Jan 24 01:42:02 alternate screen buffer Jan 24 01:43:54 Brybry, PuffTheMagic: make a copy of m_data ? Jan 24 01:44:09 is evertything int hat now? Jan 24 01:44:11 ok thats easy Jan 24 01:44:19 as well as the various state variables, i suppose, like the line pointers and margins i guess Jan 24 01:44:22 I don't want that Jan 24 01:44:43 I think I want a copy of the framebuffer I guess? Jan 24 01:44:46 line pointer? Jan 24 01:44:55 m_nTopLine Jan 24 01:44:56 or w/e Jan 24 01:46:50 you can pretty much look at redraw() I think and see what you have to copy Jan 24 01:47:02 heh, good call :) Jan 24 01:47:23 (without having to go any deeper than that function) Jan 24 01:50:08 could he also use memcopy or something or does that not work with C++ classes and the better way is to make a copy constructor? Jan 24 01:53:29 memcopy should work Jan 24 01:54:21 please don't memcpy a vector Jan 24 01:54:46 overloaded operators Jan 24 01:55:36 just use the existing copy constructors Jan 24 01:55:59 i didnt know it had one Jan 24 01:56:01 i dont do c++ ;) Jan 24 01:56:28 I was talking about TerminalState not the vector (like if he wanted to copy the whole thing) but yeah, all the stl classes already have copy constructors :) Jan 24 01:56:55 there's std::copy, too Jan 24 01:59:59 i'd made a simple struct that contains the state you need, and ahve terminalstate make use of this new struct in palce of all the related data Jan 24 02:00:22 and if you wanna back it up, just use the default assignment operator, etc, to back up the state to a variable...whose location depends on the nature of the backup Jan 24 02:00:27 and then you can copy/restore/etc with no trouble Jan 24 02:00:44 why is a struct needed? Jan 24 02:00:53 maybe not best, but should avoid some common mixups Jan 24 02:01:23 PuffTheMagic: to encapsulate the relevant data, and to not have things like m_dataBackup, m_nTopBufferLineBackup or something else wrong Jan 24 02:01:32 it's not 'needed', it was just a suggestion Jan 24 02:02:58 a suggestion i dont really understand cause I havent examined the new code base yet Jan 24 02:03:00 don't listen to me, do what seems resaonable and we'll sort out any review later. you're the one figuring out what needs to b edone when Jan 24 02:03:34 dtzWill, im also sorta in a daze, was on the road for 4 hours, back in my house which i havent been in for over a month Jan 24 02:03:40 full cause i just ate Jan 24 02:03:49 haha Jan 24 02:04:06 earning your nick? lol Jan 24 02:04:15 anyway it's all good, i'm just rambling to avoid my other work Jan 24 02:04:24 no, been almost 2 years since i did that :( Jan 24 02:06:48 :( Jan 24 02:10:07 i'm finding writing a "Research statement" entirely crippling Jan 24 02:10:44 i do very very poorly with these loosely defined tasks. the hell is a research statement? ramble on about shit i'm doing and hope to do? :/ Jan 24 02:10:54 anyway, thanks for letting me complain haha O:) Jan 24 02:26:01 dtzWill, im gonna be in the same boat this semester Jan 24 02:26:09 i need to get my dissertation proposal together Jan 24 02:26:42 aw shit Jan 24 02:26:46 you're way farther along than i am Jan 24 02:26:53 i'm jsut writing this fuck-all qual research statement Jan 24 02:26:58 that might've been due last semester >_> lol Jan 24 02:27:21 dissertation proposal==prelims? Jan 24 02:27:35 idk Jan 24 02:27:40 prob not Jan 24 02:27:45 prelims as in qualifiers? Jan 24 02:27:50 our dept doesnt do that shit Jan 24 02:27:53 ah Jan 24 02:27:55 typedef enum Jan 24 02:27:55 { Jan 24 02:27:55 TS_ALT_SCREEN_OLD, Jan 24 02:27:55 TS_ALT_SCREEN_NEW, Jan 24 02:27:55 TS_ALT_SCREEN_NEWER Jan 24 02:27:55 } TSAltScreen_t; Jan 24 02:27:58 ^^ LOL Jan 24 02:29:24 quals are first for us, after which you're free to start working on your thesis. prelims are saying "I plan to do my thesis on $FOO. I don't know how it'll work out exactly, but here's why i think it's a good idea, *convincing arguments*", passing means the faculty agrees. then you have your defense which i guess is just "i dare you to not let me graduate, just LOOK at what i've done" ;) Jan 24 02:29:26 actually, dont need that Jan 24 02:29:57 so yeah prelims==thesis proposal. in fact, although i think i've already gone too far with this, http://cs.illinois.edu/graduate/academics?quicktabs_5=1 lists prelims as "thesis proposal" so that's that Jan 24 02:29:58 so i guess its like prelims Jan 24 02:30:24 but we defend both our proposal and our actual dissertation Jan 24 02:30:57 * dtzWill nods Jan 24 02:31:15 the "you pass if you get faculty to agree" natuer of prelims was my way of saying that, if perhaps poorly Jan 24 02:31:21 anyway GL with that, is the important thing :) **** ENDING LOGGING AT Tue Jan 24 02:59:57 2012