[9fans] Page problems - Plan9

This is a discussion on [9fans] Page problems - Plan9 ; I've seen one posting about page since the recent changes, so I waited. I'm starting to wonder if I'm alone seeing problems. I've been using page mainly to review a paper I've been working on, but I've also had these ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: [9fans] Page problems

  1. [9fans] Page problems

    I've seen one posting about page since the recent changes,
    so I waited. I'm starting to wonder if I'm alone seeing problems.

    I've been using page mainly to review a paper I've been
    working on, but I've also had these problems while reading
    pdfs and plan 9 docs. Usually, page starts with a blank page.
    If I advance a page, then go back, I can see page 1. Then,
    usually after a few pages of reading, a page will show up
    with a black bottom quarter, and the mouse button menus
    start to linger around after they've been used, though I can
    still open new menus and use them.

    This is using drawterm-osx. I've reverted to the old binary,
    so it's not a big deal to me. Just thought I'd throw it out there.

    Greg

  2. Re: [9fans] Page problems

    > I've been using page mainly to review a paper I've been
    > working on, but I've also had these problems while reading
    > pdfs and plan 9 docs. Usually, page starts with a blank page.
    > If I advance a page, then go back, I can see page 1. Then,
    > usually after a few pages of reading, a page will show up
    > with a black bottom quarter, and the mouse button menus
    > start to linger around after they've been used, though I can
    > still open new menus and use them.
    >
    > This is using drawterm-osx. I've reverted to the old binary,
    > so it's not a big deal to me. Just thought I'd throw it out there.


    the cachedpage() handling appears to be new. perhaps that's
    the rub. this doesn't cause trouble on my linux drawterm.
    so there might be a quirk with osx drawterm.

    i can't test a real terminal at the moment.

    - erik


  3. Re: [9fans] Page problems

    As I said, it is weekend and I've got a little time at my hands to look
    into this. The problem is indeed with the cacheing. A quick fix is this
    change to /sys/src/cmd/page/view.c:

    136,138c136
    < if(im == nil)
    < wexits(0);
    < if(resizing)
    ---
    > if(im && resizing)


    I'm about to submit a patch with that for the powers that be. I haven't
    extensively tested the diff, but it is as unobtrusive as I could wish for.

    Martin


  4. Re: [9fans] Page problems

    I haven't read the mail properly. The diff is only aimed at my problem. I
    didn't experience Greg's symptoms, but I doubt I affected those.

    Martin


  5. Re: [9fans] Page problems

    > As I said, it is weekend and I've got a little time at my hands to look
    > into this. The problem is indeed with the cacheing. A quick fix is this
    > change to /sys/src/cmd/page/view.c:
    >
    > 136,138c136
    > < if(im == nil)
    > < wexits(0);
    > < if(resizing)
    > ---
    >> if(im && resizing)

    >
    > I'm about to submit a patch with that for the powers that be. I haven't
    > extensively tested the diff, but it is as unobtrusive as I could wish for.
    >
    > Martin


    in order for im to return nil, this test has to be true

    if((page < 0 || page >= doc->npage) && !doc->fwdonly)
    return nil;

    i think the question is, why is page out of range and what's it's value?

    - erik


  6. Re: [9fans] Page problems

    * erik quanstrom (quanstro@quanstro.net) wrote:
    > in order for im to return nil, this test has to be true
    >
    > if((page < 0 || page >= doc->npage) && !doc->fwdonly)
    > return nil;
    >
    > i think the question is, why is page out of range and what's it's value?
    >
    > - erik


    That happens at startup with the -i option. Somewhere in main is a call of
    initgfx(nil, 0, nil, nil, 0) in that case. This leads to doc->npage being 0
    which puts any value of page out of range in this case. Essentially it's
    something of a timing issue. Page wants to display an image and looks for it
    in the cache. At that point the cache is empty because page gets the data
    via the plumber and the event loop hasn't yet started to process plumbing
    messages. At least that's as far as I have understood what's going on. And
    it probably isn't the cause for Greg's problem (which I couldn't reproduce).

    Martin



  7. Re: [9fans] Page problems

    > * erik quanstrom (quanstro@quanstro.net) wrote:
    >> in order for im to return nil, this test has to be true
    >>
    >> if((page < 0 || page >= doc->npage) && !doc->fwdonly)
    >> return nil;
    >>
    >> i think the question is, why is page out of range and what's it's value?
    >>
    >> - erik

    >
    > That happens at startup with the -i option. Somewhere in main is a call of
    > initgfx(nil, 0, nil, nil, 0) in that case. This leads to doc->npage being 0
    > which puts any value of page out of range in this case. Essentially it's
    > something of a timing issue. Page wants to display an image and looks for it
    > in the cache. At that point the cache is empty because page gets the data
    > via the plumber and the event loop hasn't yet started to process plumbing
    > messages. At least that's as far as I have understood what's going on. And
    > it probably isn't the cause for Greg's problem (which I couldn't reproduce).
    >
    > Martin


    if this is a timing issue, then that should be addressed. if your diagnosis is
    correct, then if pagecache would slept until the event loop were running,
    that would fix the timing problem.

    maybe something like

    int eventdawn; /* set after event loop is fired up */

    Image*
    cachedpage(Document *doc, int angle, int page)
    {
    static int lastpage = -1;
    static int rabusy;
    Image *im;
    int ra;

    + while(eventdawn == 0)
    + sleep(1);


  8. Re: [9fans] Page problems

    * erik quanstrom (quanstro@quanstro.net) wrote:
    > if this is a timing issue, then that should be addressed. if your diagnosis is
    > correct, then if pagecache would slept until the event loop were running,
    > that would fix the timing problem.
    >
    > maybe something like
    >
    > int eventdawn; /* set after event loop is fired up */
    >
    > Image*
    > cachedpage(Document *doc, int angle, int page)
    > {
    > static int lastpage = -1;
    > static int rabusy;
    > Image *im;
    > int ra;
    >
    > + while(eventdawn == 0)
    > + sleep(1);


    I'm afraid in this instance this wouldn't help. The control flow is smething
    like main -> viewer -> { showpage -> cachedpage ; event loop }. Maybe
    the following would better:

    void
    viewer(Document *dd)
    {

+ Reply to Thread